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PREFACE 


Microprocessors developed rapidly in the 1970’s. By the end of the 
decade, large scale integration technology had reached a level that 
would support the most advanced architectures in use in minicomputers. 
The sixteen-bit microprocessors that ushered in the 1980’s are not just 
stepping stones—they are full-scale computers that will exert a major 
influence for years to come. They should be studied by anyone who 
will be working and designing with computers in the 1980’s. 

For this reason I considered a serious book on the Z8000 to be an 
important project and well worth the substantial investment of time 
and energy that it would require. This view was shared by Rodnay 
Zaks, President of Sybex, and I was provided with excellent support 
at every stage—from the design of the book’s cover to the painstaking 
execution of my flights of typographical fancy. 

Everyone at Sybex was helpful and encouraging, but there are several 
whose contributions to this book were especially valuable. I am pleased 
to be able to thank them here. 

Salley Oberlin was my typist, editor and critic. Her commitment to 
quality and her unrelenting insistence on order and clarity inspired me 
to strive for the best book I was capable of writing. 

Roger Gottlieb was responsible for turning a typed manuscript and 
a pile of hand-drawn sketches into a finished book. I shall always be 
grateful for the way he managed to involve me in all aspects of the 
book’s production. Someday, I’m sure. I’ll also be grateful for the 
way he harnessed my passion for fine tuning and endless improvements 
and diverted it into constructive paths that did not interfere with 
budgets and schedules. 

J. Trujillo Smith did the illustrations that appear in this book. His 
patient and careful drawing and redrawing of many of these 
illustrations has made them clear and unambiguous. They are full of 
subtleties; few readers will notice them all. 

Diana J. Goodin did most of the typesetting. The algorithms she 
had to devise for coaxing her machine to respond to some of my 
conceptions were as complex as many that appear in the book. 

To Guy S. Orcutt fell the thankless job of integrating corrections 
into the galleys and keeping track of the various versions as they 



passed from typesetter to author to proofreader in seemingly endless 
circles. I don’t know how he did it. 

I am also grateful for the help I received all along the way from Zilog 
and from AMD. David Stevenson and Jim Weldon of Zilog, and Steven 
Dines of AMD were especially helpful in locating information and re¬ 
solving subtle issues when the available published documentation was 
not sufficient to my needs. David Stevenson also made many helpful 
suggestions after reading parts of my original manuscript, and Steven 
Dines provided me with an early version of Figure 9.14. Zilog also 
provided copies of their original art work for the Z8001 and Z8002 
pinout diagrams. They appear here as Figure 2.11 and are reproduced 
with permission. 

A very important contribution to the accuracy of the book was 
made by Ken McKenzie, Ron de Jong and Jagi Shahani of Zilog, who 
arranged for me to have the use of a Z8000 development system, evalua¬ 
tion board and CRT. This made it possible for me to test many of the 
programs in this book. Alex Cannara was very helpful in showing me 
how to use this equipment. 

A technical review process is important to the productidn of a book 
such as this one. I wish to thank the following busy professionals for 
agreeing to read copies of the original manuscript: Dennis Allison, 
Forrest Baskett, Steven Dines, Constance Hwang, R.S. Langer, Bernard 
Peuto, David Stevenson, Rodnay Zaks. 

A special acknowledgement is due here to R.S. Langer. It was he 
who suggested to me that I write a book about the Z8000. 

A word is in order about the many programs that appear in this book. 
Their purpose is the illustration of the principles and techniques presented 
in the accompanying text. For clarity, they have not been encumbered 
by the special conventions of any specific assembler, and they have 
been typeset—not reproduced from computer output. Nonetheless, in 
the interest of accuracy, many of the programs have been translated 
into PLZ/ASM—a process that leaves the code portion virtually in¬ 
tact—and tested. The context switching routines of Figure 6.11 and 
the programs in Chapter VIII (through Figure 8.15) have all been 
tested in this way. 

Finally, let me say that the ideas and concepts presented in this book 
have many sources. While attribution has been possible in specific 
instances, many of these ideas and concepts are due to unnamed or 
multiple sources; some are simply my own interpretations of widely 
known principles of computer science and systems design. 

Berkeley, California 
March, 1980 
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Introduction 


This is a self-contained book about programming the Z8000 micro¬ 
processors: 

• It describes in detail the architecture and functioning of the Z8000 
and shows how it interacts with its family of support chips. 

•It provides an introduction to machine language programming, 
using the Z8000 as a concrete example. 

• It presents many sample Z8000 programs; these are organized 
around central themes such as interaction with an operator at a 
terminal, storage management, shareable programs and time¬ 
sharing; the main purpose of these programs is to illustrate tech¬ 
niques and principles. 

• It shows how simplicity, clarity of style, modularity and other im¬ 
portant principles of software engineering can be realized in 
machine language programming. 

This book is intended for anyone interested in using the Z8000; 
different readers will be interested in different aspects of it. For the 
person who wishes to learn machine language programming. Chapters I 
through V, the first half of Chapter VI and a small part of Chapter 
VII provide the basic course of study. Chapters II, IV, V and VII 
provide the descriptive material about the Z8000 and its family of 
chips; a design engineer who is not very interested in programming can 
read these chapters for a description of the machine and commentary 
on its strengths and weaknesses. Those who are interested in con¬ 
tinuing will find many examples in the remainder of the book; some of 
these examples may be difficult for a beginner to understand. 
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Experienced programmers (especially those familiar with similar 
CPU’s, e.g., the PDP-11) can skip Chapters I and III; but they should 
definitely study the last half of Chapter VI and Chapters VIII and IX. 

The book interweaves the introductory programming material and 
the hardware description, then it goes on to the programming examples. 

Chapter I is an introduction to programming. It covers algorithms, 
flowcharts and the various ways of representing information within 
the computer’s memory. 

Chapter II is an overview of the Z8000 architecture. Because the 
Z8000 is an advanced and sophisticated CPU, this chapter is forced to 
cover many difficult concepts. Some of this material will be hard for 
those who have never before studied a computer’s architecture. If you 
have difficulty understanding the details or the purpose of some of 
these concepts, scan the material and return for a second reading after 
you have read some of the subsequent chapters. 

Chapter III presents the complete development of a Z8000 program 
from the initial algorithm to the final code for the main routine and its 
two subroutines. The algorithm given is for encryption of text using 
the exclusive OR of characters of the text with characters of a key; this 
provides an interesting framework within which to present some con¬ 
cepts, principles and techniques. 

Chapter IV presents the Z80(X) instruction set. To aid 
understanding, the instructions have been grouped into eight cate¬ 
gories, which help to facilitate an orderly exposition. It is important to 
understand and remember the instructions, not the categories. As a 
further aid pictorial representations of instruction execution and “data 
paths” are provided; these also are only important as tools. 

At the end of Chapter IV is the basic reference manual for the in¬ 
structions. The 105 mnemonic codes for Z8000 instructions have been 
divided into 45 groups; the criterion used for grouping was that the 
instructions in a group were so similar in operation and in instruction 
format that it would be clearer to treat them as a unit than it would be 
to treat them separately. There are 45 instruction descriptions at the 
end of Chapter IV, preceded by two indices: an alphabetical listing of 
the 105 basic mnemonics, each indexed to the relevant instruction 
description; and a numeric listing of the 64 “opcodes,” each indexed 
both to the corresponding mnemonics and to their instruction descrip¬ 
tions. Since the instruction descriptions and their indices are intended 
as a reference manual. Chapter IV includes a long section describing 
their use, including examples of assembling and disassembling Z8000 
programs by hand. 
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Chapter V completes the description of CPU operation and in¬ 
structions by presenting the various Z8000 addressing modes. This 
short chapter covers the principal addressing modes (register, indirect 
register, immediate, direct and indexed), the two modes available only 
with the load instruction (based and base indexed) and the implicit 
relative addressing mode. Immediate argument and address formats in 
instructions are illustrated with examples, and the encoding of register 
fields is explained. 

Chapter VI covers input/output techniques. I/O addressing is dis¬ 
cussed, and techniques for level and pulse generation, wait loops and 
synchronous bit serial data transmission are presented. An example of 
bit serial transmission is provided by routines for a teletype. Half and 
full duplex terminal operation and parallel asynchronous data trans¬ 
mission are discussed. An example using a seven-segment display is 
worked out in detail. Finally, I/O scheduling by polling and interrupts 
is discussed, and an example of interrupt I/O routines for a terminal 
device is presented. This example involves many subtle issues that may 
be difficult to understand on first reading. 

Chapter VII deals with Z8000 peripheral components, such as the 
memory management unit and parallel and serial I/O circuits. The 
best information available to the author at the time of this writing was 
used, but future editions of this book will present more detail. Also, 
some unplanned features of the Z8000 are discussed, e.g., use of the 
REFRESH register as the basis for a clock. 

Chapter VIII contains many examples that demonstrate how the 
Z8000 can be programmed and how easy it is to build useful tools. 
One such tool sketched in detail in this chapter is a terminal handler 
that allows easy programming of interactions with an operator at a 
terminal (CRT or TTY); it uses the interrupt programs presented in 
Chapter VI and provides the fundamental routines for asking ques¬ 
tions, deciphering answers, cursor control and screen displays. Many 
other utility programs are presented in this chapter, including ring and 
line buffer handling, translation by associative search and bit table 
lookups and scans. 

Chapter IX illustrates the power of the Z8000 architecture by 
outlining a simple implementation of a timesharing system that uses 
shared programs with separate stacks for the users. Also, a technique 
for stack management is illustrated, and the details of trap handling 
and system initialization are presented. 

Finally, Chapter X deals with the program development environ¬ 
ment; issues and design considerations for editors, assemblers, loaders 
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and debug facilities are discussed. The development hardware alterna¬ 
tives, i.e., development systems and “single-board computers,” are 
also covered. 

Several appendices follow Chapter X. Appendix A contains answers 
to exercises that appear throughout the book. Appendices B, C, D and 
E reproduce charts and figures from other parts of the book, so that 
they can be used as references. 

Appendix F presents an outline of the Extended Processing Archi¬ 
tecture (EPA). This feature, which allows external chips (like a floating¬ 
point processor, for example) to be controlled by in-line instructions, 
was announced by the manufactmer after the first printing of this book. 
Appendix F explains how bit 13 of the Flag and Control Word (FCW), 
the opcodes OE and OF (hexadecimal) and the status line (ST3-ST0) 
settings A, B, and E (hexadecimal) are used to support this feature. 

This is a long book containing many factual statements and sample 
programs. The author has made every attempt to assure their 
correctness, but inevitably errors will be found. Any reports of such 
errors or other comments and criticisms will be greatly appreciated 
and will contribute to the improvement of the book in later editions. 
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Chapter I 
Basic Concepts 


This chapter will cover algorithms, flowcharts and representation of 
information. The reader who knows this material can scan through it 
quickly. 

What Is Programming? 

Programming is a skilled craft—like carpentry or writing—re¬ 
quiring training in the basics and a good deal of practice. We have raw 
materials to work with and jobs to be done. Our raw materials are the 
instructions, memory and attached devices of our computer system— 
the Z8000. As we go on we shall get a better idea of what the jobs are, 
but for now, let’s say that we solve problems. 

Algorithms 

The first thing everyone learns about computers is that they only do 
what you tell them to do, and you must tell them clearly and unam¬ 
biguously or you can get into trouble—like the man who told the genie 
to make him a milkshake. We pin down exactly what we want com¬ 
puters to do by starting with an algorithm: a list of numbered instruc¬ 
tions, called steps, in the order that we want them done. To make 
algorithms useful, we need some steps that look like: “If such-and- 
such, then skip forward (or go back) to step so-and-so.’’ This 
complicates things. We have to be sure we leave a way out so we don’t 
keep going back to step so-and-so over and over again forever. 

Figure 1.1 shows the usual way we multiply two numbers. Figure 
1.2 shows the corresponding algorithm, which will give you an idea of 
how we talk to computers. Whenever we have a new problem to solve. 
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12573 - 

Step 1 

112 


25146 - 

Step 4, first time (n = 1) 

12573 - 

Step 4, second time (n = 2) 

12573 - 

Step 4, third time (n = 3) 

1408176 - 

Step 7 


1.1: Multiplication of Two Numbers 


we have to develop an algorithm and communicate it to the computer. 

Let’s see how the algorithm of Figure 1.2 actually works in the 
example of Figure 1.1. We begin at step 1 by writing 112 under 12573 
with the 112 under the 573, then we draw a line under them. 

Step 2 is called initializing a counter. It doesn’t appear anywhere in 
the picture; it is just our way of remembering which of the three digits 
in 112 we are working with. We shall go from right to left, so n = 1 
corresponds to working with the 2; n = 2 corresponds to the middle 1; 
and n = 3 corresponds to the first 1. 

Step 3 is called testing a condition. We are going to be comparing n, 
which we just set to 1, with 3, the number of digits in 112. Naturally, 1 


1. Write the two numbers one under the other with their last 
digits lined up; draw a line under them. 

2 . Set a counter to 1. 

3. If the value, n, of the counter exceeds the number of digits 
in the second of the numbers to be multiplied, then skip to 
Step 7. 

4. Multiply the first number by the n-th digit from the right hand 
end of the second; write the answer below the line with its 
rightmost digit lined up under the digit multiplied by. 

5. Increment the counter by 1 (i.e., replace n by n H- 1). 

6 . Go back to Step 3. 

7. Add all of the numbers obtained In repetitions of Step 4; this 
Is the desired result. 


1.2: The Multiplication Algorithm 
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does not exceed 3, so we don’t skip to step 7. But as we go through to 
steps 5 and 6, we increase n to 2 and then to 3 and then to 4 and come 
back each time to compare its value with 3. When it gets up to 4 it will 
finally exceed 3, then we go on to step 7. Steps 2, 3, 5 and 6, taken 
together, are equivalent to saying: do step 4 once for each digit of the 
bottom number—that is, 3 times for 112. 

Steps 2 through 6 make up what is called a loop. Step 4 is the thing 
that is done over and over in the loop, and steps 3, 5 and 6 are the 
mechanical process we use to make step 4 happen exactly the number 
of times we want it to happen. 

Step 4, the heart of the loop, tells us to multiply 12573 by whichever 
digit of 112 we have reached and to write the answer with its last digit 
lined up under the digit we multiplied by. The reason for lining things 
up this way, of course, is that the two I’s in 112 represent 100 and 10, 
and lining up the answers under these digits saves writing final zeroes. 
In fact, the sum under the line in Figure 1.1 could be written as: 

25146 

125730 

1257300 

1408176 

If you want someone to multiply 12573 by 112, you don’t give a 
seven-step command; you just ask: “What’s 12573 times 112?’’ If the 
person has learned (and remembered) the algorithm, this abbreviated 
command will achieve the desired result. 

Similarly, once we have communicated an algorithm to the 
computer, all we need is a simple command to tell the computer to 
apply it to the case in hand. That is what subroutines are all about, 
and this avoidance of repetition is one of the reasons that subroutines 
are the programmer’s single most important tool. 

EXERCISE 1: In the multiplication algorithm of Figure 1.2 not all of the 
steps are repeated the same number of times. In applying the algorithm 
to the case 12573 x 112, how many times is step 3 performed? Are there 
any steps performed just once? What if we wrote 112 on top and 12573 
below? 

The algorithm starts at the right end of the bottom number and moves 
left. Can you make up an algorithm that starts at the left and moves right? 

How would you keep the numbers lined up properly? Try your algorithm 
on 9536 x 121. Is there any advantage to starting at the left? Suppose you 
only want an approximate answer. 
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Flowcharts 


Another way to present an algorithm is the flowchart. A flowchart 
is a graphic form of algorithm. The steps are placed in boxes; lines 
and arrows indicate the sequence of steps. The steps of the form “if 
such-and-such, then skip (or go back) to step so-and-so” are drawn as 
diamonds, and these have more than one line leaving them. A flow¬ 
chart for the multiplication algorithm is shown in Figure 1.3. The 
boxes and lines of the flowchart are labeled with the numbers of the 
steps to which they correspond. 

It doesn’t matter whether you use flowcharts or the narrative form 
to express algorithms. The important thing is to do one or the other 
before writing a program. 


EXERCISE 2: Draw a flowchart for opening your front door. Assume that 
you do it one way if it is locked, another if it is not. 


Representing Information 


There are three basic parts to a computer: a central processing unit 
(CPU) that does all the work; a stored program, which is just an 
algorithm expressed in terms of operations and decision procedures 
that the CPU is capable of carrying out; and a memory for storing the 
data that the CPU will operate on. 

Hexadecimal Representation 

Before discussing the CPU and the stored program, we shall look at 
how to represent various kinds of data in memory. Memory in all 
computers is built from bits, or binary digits, which are two-state 
elements whose states are always designated 0 and 1. Think of them as 
tiny light bulbs: off is zero, on is one. In the Z8000 the main grouping 
of bits is the 16-bit word\ words are divided into 8-bit bytes. Each byte 
consists of two 4-bit digits. Going the other way, two words are some¬ 
times combined into a 32-bit long word. Occasionally a 64-bit entity is 
also recognized by the Z8000 CPU. The actual state of the bits (lights) 
in any of these groupings is called the bit pattern or value of the byte, 
word, etc. (See Figure 1.4.) 

We represent data in memory by letting different bit patterns mean 
different things. Sometimes the same bit pattern means different things 
at different times—depending on whether it is interpreted as a number, 
a text character or something else. In fact, one source of error in ma- 
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Step 1 



Step 2 


Step 3 


Step 4 


Step 5 


Step 6 


Step 7 


1.3: Flowchart for the Multiplication Algorithm 

chine language programs—and in many “higher level” language pro¬ 
grams as well—is treating one type of data in memory as if it were some 
other type. 

Since everything depends on interpreting bit patterns, we need some 
way to talk about them. The usual way is called the hexadecimal — 
base 16—representation. Figure 1.5 gives the names assigned to each 
of the 16 possible combinations of four bits. You can see that they are 
arranged in a definite order, and that the names are not assigned at 
random. The bit patterns are ordered and interpreted as binary numbers. 
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(Computer Memory—Many Bits) 


• • • 
• • • 


\l/ \l/ \l/\l/ \l/ M/ \|/ \|/\l/ \l/ 

Q9Qe999Q0Q9Q©gggWWW 


1001011001010010110010 


• • • 
• • • 


\i/ \i/\i/ \i/ yi/ \i/ M/\i/ 

9909999999999999 


101 1001010010110 


Word: 16 bits 

Bit Pattern: 1011001010010110 


\ I / \ I / \ I /? \ I / 

99999999 

10 1 10 0 10 


Byte: 8 bits 

Bit Pattern: 10110010 


M/ 

9999 

0 0 10 

Digit: 4 bits 
Bit Pattern: 0010 


1.4: Bit Groupings and Patterns 

Hexadecimal and binary are two examples of number systems; in our 
usual decimal number system any number can be written in exactly one 
way as 


ao + a, X 10 -b a 2 X 100 -f a 3 x 1000 + . . . ; 

that is 

ao ~b ai X 10 H“ a 2 X 10^ a 3 x 10^ “b . . . 

where ao, a,, a 2 , . . . are whole numbers from 0 to 9. For example, 1980 
is our shorthand for 

0 + 8x10 + 9x100 + 1x1000 

Similarly, if b is any whole number greater than 1, it can be proved 
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that any whole number can be written in exactly one way as 


Co -f c, X b + C 2 X b^ -h C 3 X b^ + . . . 
where Co, c,, . . . are whole numbers from 0 to b - 1. For example, 

196 = 4 + 0x8 + 3x8^ 

For b = 2 and b = 16, the corresponding number systems are called 
binary and hexadecimal. When b = 2, the coefficients Co, Ci, . . . all 
take the values 0 or 1 ; so any bit pattern can be viewed as a binary 
number. 

When b = 16, the coefficients Co, c., . . . take values from 0 to 15. 
For convenience in writing them we use the following abbreviations: 
A = 10, B - 11,C = 12, D = 13,E = 14, F = 15. For example. 


196 = 4 + Cx 16 

By analogy with our decimal notation, we write the base b represen¬ 
tation 


Co + Cl X b -h C2 X b^ + C3 X b^ + . . . 


as 

For example. 


. . . C3C2C1C0 


196 = C4 


in the hexadecimal representation. 
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Since some hexadecimal numbers look just like decimal numbers, 
we write the number base as a subscript when we think that there 
might be confusion. For example, 

196,0 = 304s = C4,s 


EXERCISE 3: Express 7 as a binary number. Express 196. What is the 
relation between the binary and hexadecimal representations of 196? 

Now the assignment of bit pattern names in Figure 1.5 is clear: the 
name of each 4-bit pattern is the hexadecimal digit corresponding to 
the 4-bit binary number it represents. For example, 

1101 = 1 -b 0x2 + 1 x2^ -I- 1 X2' = 13 = D,e 

Furthermore, this hexadecimal naming can be extended to 8-bit, 16-bit 
or longer bit patterns simply by breaking the pattern into groups of 4 
bits (starting at the right if the number of bits in the pattern is not a 
multiple of 4) and giving each group of 4 bits its hexadecimal name. If 
this is done then the resulting hexadecimal name, taken as a hexa¬ 
decimal number, represents the same number as the binary number 
corresponding to the original bit pattern. Figure 1.6 shows an example 
of this. Notice how on the right side of the diagram the binary number 
is evaluated by grouping together the terms for 16, 32, 64 and 128, then 
factoring out 16. Obviously, extension of this method to longer bit 
patterns is possible, which proves what we said above. 

EXERCISE 4; Use the method of Figure 1.6 to show that 11000100, = 304,. 

If we look at base b numbers limited to n digits, that is, of the form 

Co + c, X b -t- C 2 X b^ -b ... -b Cn _ I X b" “ ‘ 

then we can express any number from 0 to b" - 1. For example, if we 
restrict ourselves to 3-digit decimal numbers, we can express any num¬ 
ber from 0 to 999 (since 999 = 10’ — 1). Since one way of distinguishing 
among the items of a group is to give each of them a number, and since 
there are b" numbers from 0 to b" - 1, another way to express this is: 
n base-b digits can distinguish b" distinct items. In particular, we have 
the following important rule: 
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(Hex name 

Bit Pattern: 11000100 

/ \ 

1100 0100 IIOOOIOO 2 (Binary number) 

) C 4 1 


0+0X2+1X4+0X8 
, + 0 X 16 + 0 X 32 + 1X 64 +1X128 

(Hex number) C4i6 1 


0+0X2+1X4+0X8 
+ (0+ 0X2 + 1 X4+1X8)X16 

1 

4+12X16 = 196.0 = 4+12X16 


1.6: Relationship between Binary and Hexadecimal 


Rule: (a) n bits can distinguish T different items. 

(b) n hex digits can distinguish 16" different items. 

For example, two bits give V = A bit patterns: 00, 01, 10, 11. We 
can distinguish four items by assigning one of these patterns to each of 
them. (See Figure 1.7.) 


Distinguishing Four Colors With 2 Bits 

9 9= Black Q Q = RecJ 

\l / \ I / \ I / 

Q Q = Green 9 9" 


1.7: Using n Bits to Distinguish 2" Items 
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EXERCISE 5: How many different items can be distinguished by 3 bits? 
How many bits are needed to distinguish 27 different items? If you are 
designing a microprocessor with 12 different states that need to be com¬ 
municated to the outside, how many status lines (bits) do you need to 
assign a different bit pattern to each of them? How many different num¬ 
bers can be represented by 4 hex digits? By 8? 


Since numbers are to be represented in hex inside the computer but 
are usually represented in decimal in the real world, we should know 
how to go back and forth between hex and decimal. Since we know how 
to do arithmetic in decimal, going from hex to decimal can be ac¬ 
complished easily using the definition of the hex representation. 
For example. 


C4,6 = 12x16 + 4 = 192 + 4 = 196 

Figure 1.8 shows an algorithm for going from decimal to hex, using 
only decimal arithmetic. The algorithm looks complicated, but it is 
quite simple. Figure 1.9 shows how it applies to the decimal number 
299. At each stage we divide by 16. The remainder becomes the next 
hex digit (going right to left) and the quotient is the starting point for 
the next stage. The last equation shows why it works; the hex number 
h 3 h 2 h,ho can be written: 

(((0 X 16 + ha) X 16 + h 2 ) X 16 + hi) x 16 + ho 


Assume given a decimal number dndn-i ... do. We wish to find 
the coefficients hm, . . . , ho such that 

(hm---ho)l6 = (clndn-l---Clo)lO 

1. Set the value of the counter k to 0. Set N = dndn-i ... do. 

2. Divide N by 16io. Let h^ be the remainder and let the new 
value of N be the quotient. 

3. If N = 0 then stop; (h^... ho)i6is the desired representation. 
Otherwise, increase the value of k by 1 and go to Step 2. 


1.8: Algorithm for Decimal-to-Hex Conversion 


14 PROGRAMMING THE Z8000 






1 X 16^ + 2 X 16 + 11 = 256 + 32 +11 = 299 
= ((0 X 16 + 1) X 16 + 2) X 16 + 11 

1.9: Conversion of 299,0 to 12Bi« 

Dividing by 16 leaves a remainder ho and a quotient 
((0 X 16 + ha) X 16 + hz) X 16 + h, 

Dividing that by 16 leaves a remainder h, and quotient 
(Ox 16 + h3)x 16 + hz 
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The next division leaves remainder h 2 and quotient 


Ox 16 -h ha 

The final division leaves remainder ha. This same scheme can be 
extended to a hex representation with any number of digits. 

EXERCISE 6: Apply the algorithm of Figure 1.8 to the decimal number 196. 

If we wish to add, subtract, multiply or divide two hex numbers, 
we can convert them to decimal, perform the operation, then convert 
back into hex. Obviously, a more direct approach is to do arithmetic 
in hex. Figure 1.10 shows the addition and multiplication tables for 
single-digit hex numbers. Extension of addition and multiplication to 
multi-digit numbers is exactly as for decimal: if the sum or product of 
two one-digit numbers results in a two-digit number, the high order 
digit is “carried” to the next place to the left. Subtraction and division 
are derived from addition and multiplication exactly as for decimal. 

For example, suppose we wish to multiply 7A,6 by 26i6. Figure 1.11 
shows this multiplication and the corresponding decimal multiplication. 
We start by multiplying 7A by 6. First we multiply A by 6 by looking 
in the multiplication table for the place where the A-row meets the 6- 
column and find 3C there. We write down C and carry the 3, then we 
find that 7x6 = 2A. We add the carried 3 to get 2D. We write this 
down, giving 2DC. Similarly, 7A x 2 = F4; we write this down with 
the 4 under the 2 of 26. Finally, we add the numbers below the line. F4 
is really F40; C + 0 = C;D-b4 = 1, carry a 1; 2-f F4-the carry of 1 = 12. 
This gives the answer 121C. 

EXERCISE 7 : What is B + B? lA + BI? A^? 

Evaluate 2B5 jlB93F. 

Two "s Complement 

So far we have talked about how, for example, a 16-bit word can be 
used to represent numbers from 0 to 65535 (since 2'^ = 65536). But, of 
course, we shall wish to express negative numbers as well. This is done 
by means of an elegant trick. 

The obvious way to handle negative numbers is to use one of our 
bits to represent the sign. Then for example, we could use the leftmost 
bit of a 16-bit word as the sign bit and the other 15 bits to represent 
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ADDITION 


01 23456789ABCDEF 



01 234567 89ABCDEF 


MULTIPLICATION 

1.10: Hex Addition and Multipiication Tables 

magnitudes of 0 to 32,767. This is called the signed magnitude repre¬ 
sentation. It is not used in the Z8000 (nor in most other computers), 
since it is harder to implement electronically than the method actually 
used and it has the additional drawback of having two representations 
of zero: -Oand -hO. 
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Hexadecimal 

Decimal 

7A 

119 

26 

34 

2DC 

476 

F4 

357 

121C 

4046 


1.11: Hexadecimal Multiplication 


The scheme actually used is called the two*s complement representa¬ 
tion of negative numbers. Two’s complement “borrows” an extra bit, 
then discards it. So in 16-bit two’s complement representation, -x is 
represented by -x; numbers greater than 2*^-1 are considered to be 
negative. The great advantage of this scheme is that two’s complement 
numbers can be added just as if they were all positive numbers, and 
the answer will come out properly, since 

X + - x) = 2'^ = 10000,6 

If we only look at the last 16 bits of 10000,6, we have 0000,6, so 

X -I- (-x) = 0 

as required. This is exactly like the behavior of a 5-digit automobile 
odometer: 99,999 miles -4- 1 mile = 0 miles. That is, on an odometer. 


-1 = 100,000 - 1 = 99,999 


A 16-bit word is like a binary odometer (or hexadecimal odometer). 
(See Figure 1.12.) 

Here are some examples of the 16-bit two’s complement representa¬ 
tion used in the Z8000: -1 = FFFF; -20 = FFEO; -8000 = 8000. 

EXERCISE 8: What is - 5 in two’s complement? What is - 7FFF? 

Subtract 1A1 from FF7 by computing the two’s complement form of - 1A1 
and adding it to FF7. 

What do you get when you add -1 to -5? What if you add -7FFE 
and -6? 
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In Chapter II we discuss registers and condition bits. When the 
Z8000 adds or subtracts it sets condition bits to let the programmer 
know what happened. One of these—the C bit—is that seventeenth bit 
we borrowed to make two’s complement work. Whenever two 16-bit 
numbers are added, the seventeenth bit is called the carry. The Z8000 
gives us the last 16 bits as the result of our addition, but it also saves 
the seventeenth bit in the C bit, in case we need to know about it. 

In the case of subtraction, however, the C bit is handled in just the 
opposite way. C is set if there was a “borrow” and cleared if not, e.g., 
for (4 - 5) C is set, and for (5 - 4) C is not set. The reason for saying 
that this is the opposite of the case with addition is that 4-5 and 4 -f 
(- 5) give different values of C. 


EXERCISE 9: Give the answer and the C bit value for each of the following 
computations: 6 - 4; BB - BC; FFFF + 3; FFFF + FFFF. 

The exercises have illustrated a problem with two’s complement 
arithmetic: arithmetic overflow. For example, 

7FFE + 6 = 8004 = - 7FFC 
In other words (in decimal), 

32766 -h 6 = -32764 

In general, when the sum of two positive numbers is negative or the 
sum of two negative numbers is positive, arithmetic overflow has 
occurred. When this happens in the Z8000, the V bit is set; otherwise it 
is cleared. This can be seen from our 5-digit odometer example. All of 
the readings from 50,000 to 99,999 represent negative numbers, so 
when we add the positive number 5 to the positive number 49,998, we 
get 50,003, which is really the negative number -49,997. This is arith¬ 
metic overflow. With 16-bit words, the 8000-FFFF range corresponds 
to the 50,000-99,999 range of the odometer. There is nothing odd 
about adding 5 to 49,998 and getting 50,003, nor is it odd to add 5 to 
7FFE and get 8003. The problem arises from the interpretation of 
50,003 or 8003 as negative numbers. In fact, there are times when we 
want to forget about two’s complement and treat the range (XXX)-FFFF 
as a range of positive numbers, corresponding to the decimal range 0 
to 65,535. This is especially true when the 16-bit number is interpreted 
as a memory address or offset—items to be discussed in later chapters. 


20 PROGRAMMING THE Z8000 



This is another reason for avoiding the use of the signed magnitude 
number representation. 

EXERCISE 10: What are the results and the C and V bit settings for: 6-4, 

BB - BC, FFFF + FFFF, - 17 + (-7FF1)? 

BCD Representation 

The two’s complement representation is supported in the Z8000 on 
8-bit and 32-bit numbers, as well as 16-bit numbers. For 8-bit numbers 
(bytes) this gives a range of —128 to +127; for 16-bit numbers the 
range is —32768 to +32767; for 32 bits the range is —2,147,483,648 to 
+ 2,147,483,647. These ranges are fine for most of our arithmetic 
needs, but sometimes the BCD representation is more convenient. 
BCD stands for binary coded decimal, but it is actually hex coded 
decimal. 

In BCD the computer stores the individual digits of a decimal num¬ 
ber in consecutive hex digits. For example, for the decimal number 
196, we make the computer store 1, 9 and 6 in consecutive hex digits; 
that is, we write 196i6 (which is actually 406lo), but we mean 196io 
(which is actually C4,6). (See Figure 1.13.) 


0 

0 , 0 . 0 . 0 


1 

0 . 0,0 


9 6 

0 , 0,1 0 . 1 , 1,0 


BCD representation of 196io 


—\ —1—1— 

-1-1-1- 

—1—1—1— 

—1—1—1— 

0 

0 

C 

4 

o 

o 

o 

o 

o 

o 

o 

o 

1 . 1 . 0 , 0 

o 

o 

o 


Two's complement representation of 196io 


1.13: BCD Representation 

Why do we do this? Because that is the way numbers usually come 
into the computer and the way they go out. If 1, 9 and 6 come into the 
computer, it is easier to store them that way than to make the com¬ 
puter convert them into C4. If you wish to put the number 196 on a 
CRT screen, you have to break it down into 1, 9 and 6; this is easier to 
do if it is stored that way. 
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EXERCISE 11: Draw a flowchart (or write an algorithm) to solve the fol¬ 
lowing problem: 

You will receive decimal digits one at a time. If you receive an “x” in¬ 
stead of a digit, you are done. You must keep accumulating a hex number 
N so that when you receive the “x,” N will already contain the hex value 
of the decimal number represented by the string of digits preceding the 
“x.” For example, if the sequence of values you receive is 1, 9, 6, x, then 
N should start at zero and successively take the hex values 1, 13, C4 (i.e., 
decimal 1, 19, 196). 

After all of the complication of going from hex to decimal and vice 
versa, you might wonder why we use hex at all. Why not just keep 
everything in BCD all the time? The answer is that some computers do 
(e.g., the IBM 1401), but the binary or hex representation is easier to 
implement electronically and is a much more efficient way to use 
memory. In BCD we use 4 bits to represent the 10 decimal digits. The 
bit patterns A, B, C, D, E and F are unused; that is, 37.5<^^o of the pos¬ 
sible bit patterns are wasted. 


EXERCISE 12: How many BCD numbers can be represented in 16 bits? 

How many hex numbers? What is the ratio of these quantities? How does 
this relate to the 10/16 ratio for four bits? What is the general rule? 

There are two more problems with BCD: one is that there is no ob¬ 
vious representation for negative numbers; the other is that the Z8000 
has no instructions for arithmetic with BCD numbers (except for a 
decimal adjust —see Chapter IV). To see why special instructions are 
needed, try adding the BCD representations of 19 and 25. The answer 
is 3E, which is not the BCD representation of 44. 

The decimal adjust command is provided for this situation. It can 
be applied to the result of adding two 2-digit BCD numbers to produce 
the desired result. For example, after adding 19 and 25, the decimal 
adjust will convert 3E into 44. 

In addition to the carry bit C, there is a half-carry bit H which the 
Z8000 sets if there is a carry out of the low order digit of a byte into 
the high order digit. 

The decimal adjust adds a “correction factor” to the byte, then sets 
C according to whether there was a decimal carry, i.e., if the answer 
exceeds 99io. 


EXERCISE 13: Write an algorithm for a decimal adjust. 

There is another bit, D, which the Z8(XX) sets after subtracting bytes 
but clears after adding bytes. Using D, modify your algorithm so it adjusts 
for either addition or subtraction. 
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We have now learned about status bits C, V, D and H; still to come 
are Z, P and S. The Z8000 sets or clears these bits under various 
conditions. Testing for whether they are set or clear is the way in 
which the diamond-shaped boxes in the flowcharts are realized in the 
computer. 

Floating Point Representation 

Finally we shall discuss the floating point number representation. 
This is analogous to the “scientific notation” used on calculators 
when the answer needs more digits than the calculator can display. In 
computers it is used for a similar reason. We saw earlier that 32 bits 
give a range approximately -2,000,000,000 to +2,000,000,000, but 
we don’t always want whole numbers. For example, for a financial 
application we might imagine a decimal point two places from the 
right, giving us a range of ±$20,000,000.00. Something like this is 
often done, so our usual representation is often called fixed point. 

The trouble with fixed point is that everything must bend to 
accommodate the most extreme case. For example, if we must accom¬ 
modate 3.14159, then our decimal point has to be at least five places 
from the right end of the number, even if nothing else needs more than 
two decimal places. The effect of placing the decimal point five places 
from the right is to limit our range to ± 20,000.00000. There are many 
applications for which that would be inadequate. 

Floating point solves this problem by segmenting the number range 
into many overlapping ranges with varying numbers of decimal 
places. Some of our 32 bits are devoted to specifying the exponent 
(roughly, the location of the decimal point) and some to specifying the 
mantissa (roughly, a fixed point number in the range specified by the 
exponent). 

For example, assume that our 32-bit long-word is divided into two 
sections: one of 8 bits representing a two’s complement exponent E 
and one of 24 bits representing a two’s complement mantissa n. (See 
Figure 1.14.) Then the actual number represented by this floating point 
number is: 


nx2"-^^ 

This is analogous to scientific notation, in which we write such 
numbers as 6.024 x \0~^\ In scientific notation we write 6.024x 10“^^ 
in preference to the many equivalent expressions, such as 6024 x 10~^^ 
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EXPONENT 


AAANTISSA 


1.14: Floating Point Representation of .34375 

or .00006024 X 10 ‘^ Similarly, we have a normal form for floating 
point numbers: it is to use the largest possible value of n (which ac¬ 
counts for the - 23 in n X 2^ “ The reason for this is easy to see. If 
we waste space in our mantissa with leading zeroes (as in .00006024 x 
10~‘^), we reduce the space available for additional significant digits. 
For example, we might only be able to write .00000060 x 10“if we 
were limited to 8 digits of mantissa. 

Of course this is a trade-off with the exponent. By normalizing, we 
could actually drive our exponent out of range. (For example, 6.024 x 
10“^^ might not be possible if we were only allowed exponents down to 
-20.) In fact, 8 bits gives us exponents in the range 2“‘^^ to that 
is, better than 10"^* to 10^*. We very seldom need numbers of finer pre¬ 
cision or greater magnitude than that. On the other hand, the 24 bits 
of mantissa give us a range of approximately ± 8 million—six signifi¬ 
cant digits—and we often need all of that, especially when 
accumulating sums of many items or forming differences of large 
numbers that are close together. 

So floating point numbers are generally normalized. The question 
of what should happen when normalizing would drive the exponent 
below its range, i.e., underflow, has received much attention. 

Figure 1.14 shows a floating point representation like the one we 
have discussed. The number represented is .34375,o. The floating point 
representation is FF580000i6. 

EXERCISE 14: 

(a) Explain why FF580000 is the floating point representation of .34375. 

(Hint: .34375 = 11 = (11 x2'’)xZ'‘-23.) 

(b) Write an algorithm for adding two floating point numbers. Leave the 
result normalized. (Hint: 6.024X 10-23 + 1.236x 10-2* = (.06024 + 
1.236)x 10-2*.) 

(c) Write an algorithm for multiplying two floating point numbers. 

Leave the result normalized. 

Floating point gives us a useful, flexible number representation. 
Unfortunately, as with BCD, the ZSOOO has no instructions that allow 
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it to operate on floating point numbers. If we wish to use floating 
point, we need to write (or obtain) & floating point package. This is a 
big job on most computers. 


Text Representation 

There was an obvious relation between the bit patterns of a byte or 
word and the numbers that we wished to represent, but nothing like 
that exists for text characters. In fact, it is not clear exactly what needs 
to be represented—do we need Chinese characters, French accent 
marks, upper and lower case letters, different type fonts, different 
colors? 

Over the years some standardization has occurred; the text charac¬ 
ters represented by “standard” codes are the upper and lower case 
characters of the English alphabet, the digits 0-9, arithmetic symbols 
/, *, =, <, >), some punctuation and frequently used 
symbols like #, $, %, &. In all there are upwards of 90 such text char¬ 
acters. 

In addition we often need to represent such device-controlling com¬ 
mands as carriage return and page eject as characters interspersed 
among encoded text. Communication over telephone lines has shown 
the need for additional control characters. 

Since all of these things have to be represented inside the computer, 
the obvious thing is to give each one a number. Such a selection and 
numbering of text and control characters is called a character code. The 
main code used with microcomputers is ASCII (The American Standard 
Code for Information Interchange). (See Figure 1.15.) 

In ASCII each text or control character is given a number between 0 
and 127. This means that 7 bits are required to accommodate all of 
the ASCII codes (since T = 128). In fact an 8-bit byte is usually used 
for each character. The eighth (high order) bit is usually zero in inter¬ 
nal representations; for transmission between the CPU and external 
devices, the eighth bit is often used for error checking. One such error 
check is parity. Odd parity means that an odd number of the eight bits 
in a character are set, while even parity means that an even number are 
set. The way this is used for error checking is to specify that all charac¬ 
ters transmitted to or from the computer will have, say, odd parity. 
Then, depending on how many bits are set in a character’s 7-bit code, 
the eighth bit is either set or cleared before transmission. The 28000 
provides an instruction for testing the parity of an 8-bit byte. The P bit 


BASIC CONCEPTS 25 



CODE CHAR 


CODE CHAR 


CODE CHAR CODE CHAR 


00 

NUL 

20 ' 


40 

@ 

60® 

V 

01 

SOH 

21 

! 

41 

A 

61 

a 

02 

STX 

22 


42 

B 

62 

b 

03 

ETX 

23 

# 

43 

C 

63 

c 

04 

EOT 

24 

$ 

44 

D 

64 

d 

05 

ENQ 

25 

% 

45 

E 

65 

e 

06 

ACK 

26 

& 

46 

F 

66 

f 

07 

BEL 

272 


47 

G 

67 

g 

08 

BS 

28 

( 

48 

H 

68 

h 

09 

TAB 
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ASCII A (even parity: 2 bits set) 
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48 = ASCII H 69 = ASCII i 
ASCII representation of "Hi" in one 16-bit word (2 bytes) 


1.16: ASCII Representation of Text 

(which is actually the same bit as the V bit) is used to report the parity. 
(See Figure 1.16.) 

Since ASCII is a 7-bit code, each ASCII character is a two-digit 
hex number between 00 and 7F. Figure I.I5 shows the assignments. 
Notice that they are not assigned at random. Instead, the upper case 
letters form a contiguous block of codes (A = 41, B = 42, ..., Z = 5 A); 
so do the lower case letters (a = 61, b = 62, ..., z = 7A) and the digits 
(0 = 30, 1 = 31, ..., 9 = 39). These facts are used in all kinds of programs. 
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EXERCISE 15: Find the sequence of ASCII characters to spell out 
“Hi! I’maZSOOO.’’ 

Don’t forget the blanks. How many bytes of storage will these characters 
occupy? 
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Chapter II 

Z8000 Hardware Organization 


In this chapter we shall cover the functional organization of the 
Z8000 microcomputers. This is important to programmers as well as 
to design engineers, because machine language programming is so in¬ 
timately involved in the details of the computer’s architecture. 

This chapter covers essentially all of the ZSOOO’s features. There is 
no way to present all of this material in one short chapter in a way that 
will be immediately clear to the reader who has never before studied a 
computer’s architecture. Nonetheless, this material is basic to what 
follows, so you should make every effort to understand it, reading 
some parts several times if necessary; but if parts of it are still unclear 
after careful study, you should go on, since most of the concepts that 
are essential to understanding the programs in this book will be ex¬ 
plained again as they are encountered. 

The Z8000 microcomputer’s architecture is more similar to that of 
the PDP-11/34 and other popular minicomputers than it is to that of 
earlier microcomputers like the Z80. Such a powerful general purpose 
machine might be uneconomical in some situations, so the Z80(X) has 
been made available in two versions: the ZSOOl and the Z8002. 

The Z8001 and its companion chip, the memory management unit 
(MMU), provide the full power of the Z80(X) design. The ZS002 single 
chip CPU is functionally equivalent to the Z8001 but is limited to a 
much smaller addressable memory. Upward compatibility is provided 
by a mode in the Z8001 in which most Z8002 programs can be run un¬ 
modified. 

The Z8000 is a 16-bit microprocessor: its data paths, instructions, 
registers, arithmetic and logical operations are all designed for 16-bit 
words. Many of its instructions can be used with long-words (32 bits). 
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bytes (8 bits) and digits (4 bits), and each byte of its memory space is 
separately addressable. 

General Purpose Registers 

The ZSOOO has sixteen general purpose registers; this means that 
each of the registers can be used as an accumulator, an index register, 
a base register or an address register. (Actually, RO can always be used 
as an accumulator, but there are restrictions on its use as an address 
register. It cannot be used as an index or base register.) 

Let’s take a moment to define these terms. 

A register is an electronic device for storing bit patterns of a given 
size—in this case 16 bits. Think of it as a row of 16 lights. 

An accumulator is a register used for keeping numbers (or 



MEMORY 


2.0: Some Uses of Registers 
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uninterpreted bit patterns) while or until arithmetic and logical opera¬ 
tions are performed on them. 

An index register is a register that holds the position of an item in a 
list (also called a table or an array)—that is, if the register holds a 5, 
then we are talking about the fifth item in some table. When we say we 
want an item out of that table “indexed by” the index register, the 
Z8000 gives us back the fifth item. Indexed addressing will be 
discussed in Chapter V. 

An address register is a register that holds the memory address of 
the item the computer is about to use (for example, the H^L register 
pair in the Z80). In Chapter V we shall discuss the indirect register 
addressing mode. 

A base register is like an address register in that it holds a memory 
address, but it is used in conjunction with an offset, or index, pro¬ 
vided separately, which is added to the address in the base register to 
obtain the address of the item the computer is about to use. The based 
and base indexed addressing modes will be discussed in Chapter V. 

The Z8000’s 16 general purpose registers can also be subdivided and 
combined in several ways. The registers are called RO, Rl, ..., R15. 
They can be combined into eight register pairs: RRO, RR2, ..., RR14. 
RO is the high-order portion of RRO and Rl is the low-order portion. 
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2.1: Z8000 General Purpose Register Hierarchy 
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and similarly for the others. The registers can also be further 
combined into register quadruples: RQO, RQ4, RQ8, RQ12; RRO is 
the high order half of RQO and RR2 is the low order half, etc. Finally, 
the first eight registers RO, Rl,..., R7 can be subdivided into “H” and 
“L” (high order and low order) byte registers: RHO, RLO, RHl, RLl, 
..., RH7, RL7. Figure 2.1 shows all of this. 

Only 8 of the registers can be divided into byte registers because if 
there were more than 16 byte registers, then there would need to be 
more than 4 bits used in instructions to specify which byte register to 
use. In a computer with 16-bit instruction words, the assignment of 
each bit must be carefully weighed against the potential benefits; a 
gain of 16 byte registers isn’t worth the price of an extra bit in register 
specification fields. The details of instruction formats will be 
discussed in Chapter IV. 

Stacks 

The Z8000 registers and instructions are designed to facilitate the 
use of stacks. A stack gets its name from the stack of plates in a well 
with a spring on the bottom, like those found on steam tables and 
salad bars. The last item added to the stack is the first one removed, so 
it is also called a last in first out (LIFO) buffer. 

With the stack of plates, the top stays fixed and the bottom moves 
up and down as plates are removed or added. In a computer it is easier 
to implement the other way around, so items never move once they are 
added to the stack; instead the stack pointer always points to the 
location in memory that contains the last item added to the stack. 

For now, think of the Z8000’s memory as a sequence of 16-bit 
registers each of which has a number (called an address). A stack 
pointer is an address register that points at the memory location that is 
the current top of the stack (see Figure 2.2). When something is pushed 
(added) onto the stack, it is placed in the next location after the cur¬ 
rent top, and the stack pointer is changed to point to the new top. 
When something is popped (removed) from the stack, the location it 
occupied becomes free, and the stack pointer is changed to point to 
the next element down, which becomes the new top. 

Every address register in the Z8000 can also be a stack pointer, and 
there are Z8000 instructions for pushing and popping. Incidentally, as 
Figure 2.2 shows, the bottom of a stack has the highest address and 
each item pushed onto the stack gets the next lower address than the 
previous top. It could just as easily have been done the other way, but 
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2.2 Stacks 
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this scheme provides a flexible way of letting a stack share memory 
with other data or programs: start them at opposite ends of memory 
and let them grow toward one another; or start them back to back and 
let them grow in opposite directions. 

The ZSOOO designates one particular address register as the stack 
pointer for certain stack operations that happen automatically: 
storing subroutine returns or storing processor status when interrupts 
or traps occur. (We shall discuss interrupts and traps later in this 
chapter and subroutines in Chapter III.) The register designated 
depends upon whether the ZSOOO is operating in its segmented or its 
non-segmented mode. Now we shall explain what that means. 

Memory Segmentation 

The ZSOOO is byte-addressable: each byte of memory has its own ad¬ 
dress. Since the 16-bit registers Rl, R2, ..., R15 can be address regis¬ 
ters, this means that there can be only 2‘* different addresses (remem¬ 
ber our rule: n bits dintinguish 2" items). That is, a ZSOOO address 
range should contain 65,536 bytes. In fact, the ZSOOO arehitecture 
allows for 12S of these 65,536-byte ranges. 

There are two modes of operation. In one, called non-segmented, 
the ZSOOO CPU executes programs that stay in one of these 65,536- 
byte ranges. All addresses are 16 bits, and the program has no explicit 
way to do anything affecting any other range. In the other mode of 
operation, called segmented, the ZSOOO CPU recognizes addresses in a 
two-word format that allows direct addressing of any byte in any of the 
12S address ranges. Figure 2.3 shows how this two-word address format 
appears in any of the long-word registers RR2, RR4, ..., RR14 that 
can be used as address registers in the segmented mode. 
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2.3: Register Format of Segmented Addresses 

In the section on stacks we said that one address register was desig¬ 
nated as the implied stack pointer, that is, the register used for storing 
subroutine returns or processor status automatically. In non-segmented 
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mode, R15 is the stack pointer; in segmented mode, RR14 is the stack 
pointer. 

Despite the fact that 23-bit addresses are used in segmented mode 
while 16-bit addresses are used in non-segmented mode, instructions 
for the two modes are very similar. This is because in the Z8000 archi¬ 
tecture, addresses need only occur in two places; in address registers 
and as part of instructions. Instructions using address registers to 
specify their arguments are identical in format in the two modes. When 
an address appears in an instruction, it is always appended to the end 
of the basic instruction. In non-segmented mode a one-word address is 
appended; in segmented mode a segmented address in one of two 
formats is appended; in either case, the basic instruction to which the 
address is appended is the same. 

One area in which the two modes might have different instructions 
would be in the loading of addresses into registers, but a special in¬ 
struction (LDA) is provided to load the address of its argument into 
an address register. The form of this instruction is the same for both 
modes. 

Memory Mapping 

So far this separation of Z8000 memory into 128 address ranges 
seems like a way to have a machine with a large memory capacity but 
with relatively short instructions and small address registers. In fact, 
that may have been the original motivation, but it becomes a scheme 
of much greater power and flexibility with the addition of one more 
'xdtdL—memory mapping. 

The basic operation of memory mapping is as follows: the 23-bit 
segmented address is treated as a logical address. The actual physical 
address it corresponds to is arrived at by a computation. The 7-bit 
segment number is translated (mapped) into an address in actual 
physical memory that becomes the start of the 65,536-byte range of 
addresses for that segment. (See Figure 2.5.) 

Given this basic idea there are many elaborations: 

• Segments need not all be the same size; some can be smaller than 
65,536 bytes. (See Figure 2.4.) 

• Segments can overlap in physical memory. (See Figure 2.4.) 

• Certain attributes of segments can be remembered and actions 
incompatible with these attributes can be intercepted (e.g., don’t 
allow writing into a read-only segment). 

• Location and attributes of segments can be changed dynamically. 
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2.4: Some Aspects of Memory Mapping 

Such elaborations involve support logic, and the Z8000 architecture 
calls for this support to be provided by an external memory mapping 
Mn/t(MMU). 

If the MMU were to work as described above, it would have to take 
as input the 23-bit address output by the Z8000, translate the 7-bit 
segment portion into a physical base address, add the 16-bit offset to 
the base address and put out the resulting physical address. Since the 
Z8(XX) system architecture calls for a 24-bit physical address, this 
means that the MMU would have 24-bit internal registers and arithme¬ 
tic and at least 23 pins of address input and 24 of address output. 

To reduce this complexity, physical memory is only mapped in 
blocks of 256 bytes. The low-order 8 bits of the 16-bit offset go 
directly to physical memory. The MMU translates the 7-bit segment into 
the upper 16 bits of a 24-bit physical base address and adds the upper 
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2.5: Mapped Address Computation 

eight bits of the offset to that value to obtain the upper 16 bits of the 
physical address. Figure 2.5 illustrates that computation. This scheme 
results in a small loss of flexibility but a large simplification of the 
MMU. 

We won’t go into detail here on how the information about segment 
location and attributes is specified to the MMU. This information is 
transmitted from the Z8000 as if to an I/O peripheral, but since 
address lines 7 through 0 are not used by the MMU, all information 
passes over lines 15-8. In Chapters IV and VII we talk about the 
special class of I/O instructions that help with this problem. 
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One MMU can handle up to 64 segments; two are sufficient to 
handle the full 8,388,608 bytes addressable by a Z8000. 

Multiple Address Spaces 

The 8,388,608 bytes addressable by the Z8000 are called the ZSOOO’s 
address space, but in fact, the Z8000 design calls for up to six such 
address spaces. The way it does so is to provide additional status in¬ 
formation that allows external logic to select different MMU’s (or 
different physical memories) for different types of reference (e.g., 
instruction fetches as opposed to data references). 

The three types of reference distinguished by status information 
are: stack reference, instruction fetch, and data reference. Further¬ 
more (see below), there is a status line distinguishing system and normal 
modes, so there can be up to six separate address spaces. 

In addition to the absolute protection afforded by complete separa¬ 
tion of these spaces, the memory capacity of the Z80()0 is greatly 
increased; this is especially important for the Z8(X)2 with its limitation 
of 65,536 distinct byte addresses. 

On the other hand, we shall see in Chapters IV and V that any attempt 
to separate address spaces in this way can lead to difficulties. 

System and Normal Modes 

Since the Z8000 architecture provides for large configurations, 
possibly with several programs running concurrently, we need a way 
to keep faulty programs from interfering with others. Also, good 
program organization requires that certain key functions be centralized and 
accessed in controlled ways. These ideas, and variations on them, led 
in earlier large computer systems to the concept of privileged instruc¬ 
tions: there is a system mode in which all instructions can be executed 
and a normal mode in which the privileged instructions cannot be 
executed. 

The system and normal modes use different stack pointers. In either 
mode the register is referred to as R15 (or RR14 if segmented). There 
is no way for a program running in normal mode to have access to the 
system mode stack pointer, but in system mode the normal stack 
pointer can be accessed as a control register called NSP. We shall 
discuss the control registers a little later in this chapter. 
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The Z8001 and the Z8002 


Up to this point we have talked about the ZSOOO as a single pro¬ 
cessor that has segmented and non-segmented modes of operation. 
We have actually been describing the Z8001. There is a stripped-down 
version called the Z8002, which cannot run in segmented mode and 
has an address range of 65,536 bytes. Most programs written for the 
Z8002 can be run on a non-segmented Z8001 in one of its segments. 
The Z8002 chip has exactly the same pin functions as the Z8001, 
except for the seven segment lines and the one line (segment trap) 
coming back to the Z8001 from the MMU. 

Since this is a book on programming the Z8000, and since the Z8001 
will run all Z8002 programs, there isn’t much need to talk about the 
Z8002; however, there are a few ways in which a non-segmented 
Z8001 differs from a Z8002; we shall mention them as we go along. 

CPU Status 

We have talked about the program address space of the Z8000 and 
of the way that the stored instructions are executed like the steps of an 
algorithm. The CPU keeps its place in the program address space (i.e., 
remembers which step of the algorithm it is doing) with the program 
counter (PC). The PC always contains the address in program space 
from which the next instruction is to be fetched. Each time an 
instruction is fetched, the PC is left pointing at the next one. The 
sequence of the program is like the sequence of rectangular boxes on a 
flowchart. The instructions corresponding to the diamond-shaped 
boxes change the PC. 

The PC is a dedicated-function address register that makes up half 
of what is called the CPU status. The other half is the Flag/Control 
Word (FCW). (See Figure 2.6.) The instructions corresponding to the 
diamond-shaped flowchart boxes depend upon the low-order byte of 
FCW, called FLAGS. FLAGS is the group of bits that we discussed 
briefly in Chapter I: C, Z, S, V (also known as P), D and H. In Chap¬ 
ter IV, as we go through the Z8000 instruction set, we shall say which 
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2.6: Bit Assignments in Flag Control Word(FCW) 
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instructions affect which bits and in which way. For now, here is how 
they are usually used: 

C: Arithmetic carry out of byte, word or long-word. 

Z: The last operation gave a zero result. 

S: The last operation left the high order (sign) bit set, i.e., the 
result was negative. 

V: Arithmetic overflow (e.g., sum of two positive numbers is 
negative). 

P: Parity of the byte tested is even. 

D,H: Used by the DAB instruction after adding or subtracting bytes. 

The other half of FCW contains four control bits: two operational 
mode bits and two interrupt enable bits. We discuss interrupts later in 
this chapter; for now, these enable bits control whether the 
corresponding interrupts will be serviced or whether they will sit and 
wait. The control bits in the FCW are: 

SEG: Set to run in segmented mode, clear for non-segmented. 

S/N: Set to run in system mode, clear for normal mode. 

VIE: Set to enable vectored interrupts, clear to mask them. 

NVIE: Set to enable non-vectored interrupts, clear to mask them. 

The PC of the Z8001 is a two-word address register in the format of 
Figure 2.3. When the Z8001 runs non-segmented, the segment portion 
of the PC does not change, but it is still sent out of the chip on the 
segment number pins. In the Z8002, the PC is a 16-bit register; there 
are no segment number pins. 

The FCW, on the other hand, is always the same. It is a 16-bit 
dedicated register. The PC and FCW together make up the CPU 
status, but there are several complications. 

The CPU status is treated as a unit in two cases: it is saved on the 
stack when interrupts occur (see the next section), and it can be loaded 
from memory with the LDPS instruction. The LDPS instruction 
recognizes one format for segmented operation and another for non- 
segmented. The non-segmented form is a long-word with FCW in the 
high order word and PC in the low order word; the segmented is four 
words: a 0, the FCW, and a 2-word PC. On the other hand the CPU 
status saved on the stack is in one format for the Z8002 and another 
for the Z8001, regardless of segmentation mode. In the Z8002 it is the 
long-word (FCW, PC) just as for the non-segmented version for 
LDPS, but in the Z8001, it is three words: FCW followed by the two- 
word PC. Figure 2.7 shows all of this. 
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This is an important point of incompatibility between the Z8002 
and the non-segmented ZSOOl; we shall discuss the consequences in 
more detail in Chapter IX when we talk about passing arguments to 
routines invoked by a system call trap. 

Traps and Interrupts 

We have all had the experience of being interrupted and then trying 
to return to where we were after dealing with the interruption. 

Interruptions are annoying, but our ability to deal with them is an 
important facet of our human intelligence. If we always had to finish 
one thing before beginning another or if we always had to restart the 
interrupted task from the beginning, then our capabilities would be 
greatly reduced. 

Interruptions can come from an external source—someone or 
something else—or we can interrupt ourselves, as we suddenly think 
of something more important than what we are doing. 

This is similar to what happens in a computer. When “someone else” 
interrupts, it is called an interrupt; when the computer interrupts itself, 
it is called a trap. 

How do we manage to resume what we were doing after dealing 
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with an interruption? We may put a bookmark in our book or make a 
“mental note” of where we were. Somehow we preserve enough of the 
status of what we were doing to allow us to get back to it. 

The Z8000 does the same: when it is interrupted it pushes the CPU 
status onto the system stack; after it deals with the interruption it 
restores the CPU status by popping the saved values back into FCW 
and PC. 

In addition to this means of remembering its status, the Z8000 needs 
a way to tell what caused the interrupt or trap. This is a word (called the 
reason) that is pushed onto the stack after the CPU status; the reason 
is supplied by the external interrupting device or by the CPU in the 
case of traps. (See Figure 2.8.) 
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2.8: Stack after an Interrupt 
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An interrupt is usually associated with an I/O device. For example, 
the printer may be ready for another character, someone may have 
struck a key on the CRT keyboard, or any number of other devices 
might want attention. A trap is caused by the execution (or attempted 
execution) of an instruction. A system call trap is a means of allowing 
a routine running in normal mode to call on one of 256 separate sys¬ 
tem routines. All of the others indicate error conditions, such as using 
an unimplemented instruction, using a privileged instruction while in 
normal mode, trying to access a segmented address that conflicts with 
the MMU’s segment attribute tables. (See Chapter IX.) 

For traps, the reason pushed onto the stack is the first word of the 
instruction causing the trap, except for a segmentation trap—for that 
the MMU identifier is in the high order byte and nothing predictable is 
in the low order. For interrupting devices, the 16 bits that make up the 
reason are available for any status information that might be useful. 
The only requirement is that for the vectored interrupt, the low order 
byte of the reason must be an index to a 256-word table of processing 
routine addresses. 

This table of addresses is part of the program status area (PSA), a 
user-defined area in program memory pointed to by a control register 
called the program status area pointer (PSAP). Figure 2.9 shows the 
layout of the program status area. The addresses given are relative to 
the starting address specified in PSAP. Incidentally, the last 8 bits of 
PSAP are forced to zero, so the PSA always starts on a block 
boundary in physical memory. The factor s takes the value 1 or 2 
because of the two different in-memory formats for CPU status (see 
Figure 2.7). The actual length of the PSA is determined by the maxi¬ 
mum possible vectored interrupt index. 

When a trap or interrupt happens, the CPU status is pushed onto 
the system stack, followed by the reason; then the new CPU status is 
loaded from the program status block corresponding to the particular 
trap or interrupt. The act of loading the new CPU status transfers the 
CPU to the routine provided by the user for processing the given 
interrupt or trap (since a PC value is part of the status). When that 
routine finishes it executes an interrupt return instruction, which 
causes the reason and saved CPU status to be popped from the system 
stack. The reason is discarded, and the saved status is reinstated, 
thereby returning the ZSOOO to what it was doing before it was 
interrupted. One tricky point: on internal traps (privileged or unimple¬ 
mented instruction) caused by multiple-word instructions, the saved 
PC points at the second word of the instruction. 
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Program Status for 
System Call Trap 



Program Status for 
Segmentation Trap 


Program Status for 
Non-Maskable Interrupt 
(NMI) 


Program Status for 
Non-Vectored Interrupt 
(NVI) 


FCW for Vectored Interrupt 


PC for Int/^fO 


PC for Int Ms 


PCforlnt^2s 


PC for Int #256 — 


Vectored Interrupt 
PC table—indexed by 
low-order byte of 
'Veason." 


10s The address x of the final vec¬ 

tored interrupt PC is ICs + 2CX). That 
is, the PC table is 512 bytes long, 
regardless of the value of s. Note 
that when s = 2, the vectored In¬ 
terrupts numbered 1,3,5,... don't 
exist. They must not be used. 

18s 



Program Status for 
Typical Vectored Interrupt 



2.9: Program Status for Interrupts and Traps 














Except in very specialized situations, the interrupt processing routine 
needs to leave the general purpose registers unaffected by its 
operation, since an interrupt can usually occur at any time, regardless 
of what the processor is working on. If it were to leave a register 
changed, it would appear to the interrupted program that a register 
changed of its own accord between two consecutive instructions, and 
this would make normal programming impossible. So the interrupt 
routine must save and later restore any registers it needs to use. We 
shall discuss this in Chapter IX. 

The three types of interrupt are: non-maskable interrupt (NMI), 
non-vectored interrupt (NVI), and vectored interrupt (VI). The NMI 
is usually reserved for something that can’t wait, like a power fail 
warning, since it can’t be blocked out. The NVI and VI are maskable 
interrupts. That means that they just sit there waiting until their 
enable bits NVIE and VIE are set in the FCW. The NVI relies on the 
program to figure out what caused it; it requires simpler hardware 
logic than a VI, since it doesn’t need to put an index into the low-order 
8 bits of reason. The VI relies on the interrupting device to put an 
index into the low order 8 bits of reason, and the CPU automatically 
uses that index to choose one of the PC values from the vectored 
interrupt table. For a Z8001 the index must be an even number (0, 2, 
4, ..., 254). (See Figure 2.9.) 

Control Registers 

In the course of the preceding discussion, we have encountered 
several control registers. Basically, there are four: FCW, PSAP, NSP 
and REFRESH. The low order byte of FCW is called FLAGS and can 
be accessed separately. PSAP and NSP are address registers. In the 
segmented version they have separate segment and offset parts called 
PSAPSEG, PSAPOFF, NSPSEG, NSPOFF, and they must be 
accessed by those names, since there are no double-word transfers to 
or from these registers. This is an important point: 

CAUTION: Since the double-word version PSAP must be changed 
in two steps, provision must be made to protect against 
interrupts occurring between the two steps. 

For example, if a non-maskable interrupt were to occur while PSAP 
was half one thing and half another, the intermediate state would have 
to correspond to the address of a valid PSA. This is possible, but 
awkward. 

The last control register is called REFRESH. This feature of the 
Z8000 architecture may be unfamiliar to minicomputer users, but the 
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idea is quite simple. A dynamic memory is an inexpensive RAM that 
can only remember things for about a millisecond. What makes it 
useful is refresh circuitry, a mechanism that keeps stepping through 
the locations of the dynamic memory just reading their contents and 
writing them back. 

The Z8000 provides the REFRESH register to assist the refresh 
circuitry. It keeps track of what row of the memory is to be refreshed 
next (a sort of PC for the refresh circuitry), and it controls the fre¬ 
quency of refresh cycles. The REFRESH register consists of an enable 
bit (RE), a 6-bit RATE field and a 9-bit ROW counter field (see Figure 
2 . 10 ). 

The Z80(X)’s operations are synchronized by a clock input that can 
run as fast as one cycle (clock tick) every 250 ns or as slow as one cycle 
every 2 jus. The RATE field determines how often the Z80(X) will pause 
for a refresh cycle. A value of 1 means once every 4 clock cycles, 2 
means every 8 cycles, 3 means every 12, etc. A refresh cycle is 3 clock 
cycles long. By comparison Z8000 instructions can hold the CPU for 
from 3 to 10 clock cycles at a time. (Incidentally, the timer associated 
with the REFRESH register keeps running, so that even if one refresh 
cycle is delayed waiting for an instruction to finish, the timer will 
signal for the next one when it is due, exactly as if the first one had 
started on time.) 

During the refresh cycle the contents of the 9-bit ROW field are sent 
out to the refresh circuitry; then the ROW is incremented by two. That 
is, the ROW field is actually an eight-bit word counter that looks like a 
9-bit byte counter. Its low order bit is always zero. 

When the CPU is in the STOP state, it goes through refresh cycles 
continuously, allowing an external refresh circuit to be used. The 
RATE field isn’t used when the CPU is stopped, but, of course, the 
ROW counter is incremented by two each time. 

Distributed Processing 

One feature of the Z8000 design that is very forward-looking is its 
provision for sharing of resources by networks of CPU’s. This is what 
distributed processing is all about. 

Distributed processing is one way to make large applications 
manageable by small programs. The task is broken down into modules, 
and each module has its own little system. The little systems talk with 
each other when they need to, but for the most part they go about 
their business independently. 
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2.10: Field Locations in REFRESH Register 

Are a lot of little systems less complicated than one big one? Here is 
a “plausibility argument.” Consider a system with 20 things going on. 
Elementary math says that there are 

20 X 19 


possible interactions between pairs of them (forget about 3-way inter¬ 
actions, etc.). Now suppose that the 20 things are separated into five 
groups of four things in such a way that there are interactions within 
each group and interactions between whole groups but none between 
parts of one group and parts of another. Then there are 

4x3 

interactions inside each group and 

^ = 10 
2 

interactions between groups for a total of 

5 X 6 + 10 = 40 


possible interactions. 

So now there are 40 interactions to worry about instead of 190. 
Breaking the problem into five modules reduced its complexity by 
nearly a factor of five. (Is there a general law here?) 

The general idea in the Z8000 design is that when the 20 tasks have 
been divided into five groups of four, each group might have its own 
CPU, some memory, I/O interfacing and so on. But suppose, for sake 
of illustration, that these groups need to share a lineprinter. 
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Since the various processes probably don’t want their output inter¬ 
spersed, the lineprinter’s “busy” status is not sufficient for control¬ 
ling access to it. So each CPU needs some way to assert control over 
the lineprinter to keep others from using it, even though it appears to 
be sitting idle. 

The mechanism to implement this uses a ZSOOO output MO, an input 
MI, and an external 4-bit bus with external bus logic to relate the four 
bus lines to the two CPU pins. We won’t go into the bus protocols or 
the external logic. We shall simply state the internal CPU protocol 
they give rise to: 

(1) If you want to use the shared resource, look at your MI line. 
If you see an “in-use” signal, give up and try again later. 
Otherwise assert your MO line. 

(2) Wait for your signal to propagate around the bus; then look 
at MI again. 

(3) If you see an “in-use” signal, that means that your signal 
made it through the daisy chain. Proceed to use the resource. 
Otherwise clear your MO line and try again later. 

(4) After finishing with the resource, clear your MO line. 

The CPU Chip 

The 48 signals available at the pins of a Z8001 (or 40 for the Z8002) 
fall into several groups, all of which were discussed or alluded to in 
this chapter. (See Figure 2.11.) 

• Address/Data Bus: The lines ADis-ADo are multiplexed address 
and data lines; they are used both for memory references and for 
I/O. (See Chapters VI and VII.) 

• Bus Control: There are three CPU outputs that say what is on 
the bus and signal when it is valid. 

AS: address strobe—means addresses on the bus are valid. 
MREQ: memory request—means that bus lines hold a memory 
address, otherwise it is an I/O address. 

DS: data strobe—for I/O data timing. 

Then there are two handshaking lines to allow devices other than 
the CPU to use the bus. 

BUSRQ: bus request—input to the CPU to request use of the 
bus. 

BUSAK: bus acknowledge—output by the CPU to grant con¬ 
trol to requester. 


48 


PROGRAMMING THE 28000 



ADoCI 

1 

48 

;□ ADa 





AD9[^ 

2 

47 

;□ SNa 





AD 10 C 

3 

46 

^ SNs 





n 

Q 

< 

4 

45 

^ AD 7 





AD 12 C 

5 

44 

di ADa 

ADa d 

1 

40 

d ADo 

ADi3 

6 

43 

AD 4 

AD 10 d 

2 

39 

d ADa 

STOP C 

7 

42 

di SN 4 

ADn d 

3 

38 

d AD 7 

BTiC 

8 

41 

dl ADs 

AD 12 di 

4 

37 

d ADe 

adi5 l; 

9 

40 

□ AD 3 

ADi 3 d 

5 

36 

d AD 4 

ADu C 

10 

39 

dl AD 2 

STOP d 

6 

35 

d ADs 

Vcc d 

11 

38 

d ADi 

M, d 

7 

34 

d AD 3 

vtlZ 

12 

37 

d SN 2 

ADi 5 d 

8 

33 

d AD 2 

NVI d 

13 

36 

d GND 

ADu d 

9 

32 

d ADi 

SE^ CZ 

14 

35 

1 CLOCK 

Vcc d 

10 

Z8002 31 

d gnd 

HW d 

15 

34 

□ as 

vTd 

11 

30 

d CLOCK 

RESET 

16 

33 

1 DECOUPLE 

NVI d 

12 

29 

d ^ 

Mod 

17 

32 

1 B/W 

Nm I 

13 

28 

1 DECOUPLE 


18 

31 

1 N/S 

RESET I 

14 

27 

1 B/W 

DS 

19 

30 

1 R/W 

Mod 

15 

26 

1 N/S 

ST 3 d 

20 

29 

1 BUSAK 

MREQ d 

16 

25 

1 R/W 

ST 2 d 

21 

28 

1 W^ 

DS d 

17 

24 

1 BUSAK 

sTi 

22 

27 

1 BUSRQ 

ST 3 d 

18 

23 

1 WATT 

sTo □; 

23 

26 

d SNo 

ST 2 d 

19 

22 

I BUSRQ 

SN 3 d 

24 

25 

1 SNi 

ST.d 

20 

21 

d STo 


2.11: Z8001 and Z8002 Pin Assignments 
(Courtesy of Zilog, Inc.) 


• CPU Control: There are two input lines that let external devices 
control the CPU. 

WAIT: wait—means that the I/O device or memory unit is 
not yet ready for a data transfer. 

STOP: stop—puts CPU into a stop state (useful for implQ- 
mcntingsisinglestep debugging mode). 

• Status: There are seven status signals output by the CPU. 

R/W: read/write—tells whether the CPU is reading from or 
writing to memory. 

B/W: byte/word—tells whether a byte or a word request is on 
the bus. 

N/S: normal/system—tells whether the CPU is in normal 
mode or system mode. 

ST 3 -ST 0 : status—encodes 12 CPU states (see Figure 2.12). 
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ST,—STe Meaning 
(hex) 

ST,—STo Meaning 
(hex) 

0 Internal operation 

8 Data memory space 

1 Refresh cycle 

9 Stack memory space 

2 I/O request 

A (Unused) 

3 Special I/O request 

B (Unused) 

4 Acknowledge: Segment trap 

C Program memory space 

5 Acknowledge: NMI 

(Subsequent Words) 


D Program memory space 

6 Acknowledge: NVI 

(First Instruction Word) 

7 Acknowledge: VI 

E (Unused) 


F (Unused) 


2.12: Encoding of Z8000 Status Outputs 

• Interrupts: There is one line for each of the three interrupt types. 

NMI : non-maskable interrupt. 

NVI: non-vectored interrupt. 

VI: vectored interrupt. 

• Distributed Processing Synchronization: These are the MI and 
MO lines discussed earlier. 

MI: multi-micro in—means that some microprocessor claims 
the shared resource. 

MO: multi-micro out—means that this processor claims the 
shared resource. 

• External Chip Support: 

Vcc: + 5 volts 
GND: ground 

CLK: clock—5 volt single phase input. 

• In itializati on: 

RESET: reset—forces the CPU to an initial state; and stack- 
format CPU status is taken from location 2, segment zero. 

• Memory Segmentation (only on the Z8001): 

SNe-SN p: segment number— output from CPU to MMU. 
SECT: segment trap—signal from the MMU to the CPU that 
a request is inconsistent with the MMU’s internal tables. 
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Chapter III 

Elementary Programming Techniques 


This chapter is an introduction to writing actual Z8000 programs. 
As with Chapter II, you should make every effort to understand it, 
rereading unclear parts if necessary, but if something is still unclear, 
then go on. There is no non-trivial way to present this subject linearly. 
Some things will make better sense after you have read the following 
chapters. 

The discussion does not refer to any particular ZSOOO assembler, so 
there are no constructions like 


do.,,od 
if... then...else 

and others that may be commonly available. We shall discuss actual 
development tools in Chapter X. 

In this chapter we shall start with a small but non-trivial algorithm 
and follow from start to finish the sequence of steps necessary to pro¬ 
duce a complete program to implement it. The algorithm is for en¬ 
crypting a block of text so that it looks like gibberish to anyone casually 
inspecting it. The idea for the algorithm comes from the RATFOR 
program “crypt” presented in the book Software Tools by Kernighan 
and Plauger—a very useful book. 

Encryption is simply the process of transforming a recognizable 
message into an unrecognizable message in such a way that the intended 
recipient will be able to decode it, but no one else who happens to see 
it will understand what it says. For example, take the message “meet 
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me at eight.” Suppose we decide to replace each letter of the message 
by the one after it in the alphabet, so m is replaced by n, e by f, t by u, 
etc. The message becomes “nffu nf bu fjhiu.” A recipient who knows 
the encryption scheme used can “decrypt” the message by working 
backward—replacing each letter by the one before it in the alphabet. 

The encryption scheme described above is so simple that an ex¬ 
perienced codebreaker could decrypt it in a few minutes without being 
told the scheme in advance. One reason it is so easy is that the same 
scheme is applied to each letter. Once you find out that f is the code 
for e, you have four of the thirteen letters. You know that the message 
has the form 


“_ee_ _e_e_” 

Then thinking about the possible two-letter words ending in “e” and 
noticing that the first two words begin with the same letter, you 
quickly come to 


“meet me _t e_t” 

and it just takes a good guess from there. And as for getting the “e” 
to start with, you only have to try the various letters that can appear as 
a double letter in the middle of a four-letter word. 

The encryption scheme of our algorithm is one step above this very 
simple one, in that it applies different encryption schemes to the dif¬ 
ferent positions in the message. For example, it may have three en¬ 
cryption schemes. In that case it applies the first to the first letter of 
the message, the second scheme to the second letter, the third to the 
third; then it repeats by applying the first scheme to the fourth letter, 
the second to the fifth and so on. 

The different schemes applied to the different positions have to be 
understood by the receiver, or the receiver won’t have an easy time 
decrypting the message. This is accomplished by giving each scheme a 
one-letter name: the A-scheme, the B-scheme, etc. Then the shorthand 
way of telling the receiver what schemes are being used is to put their 
names together into a word called the key. So if the key is “CAT,” 
that means that the C-scheme is used on the first, fourth, seventh, 
etc., positions; the A-scheme is used on the second, fifth, eighth, etc.; 
the T-scheme is used on the third, sixth, ninth, etc. 

The final piece of cleverness is to define the A-scheme, B-scheme, 
etc., in terms of the ASCII codes for A, B, etc. That way, instead of 
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having to look in a book that says what the A-scheme, B-scheme, etc. 
are, the receiver need only know the formula by which the A-scheme is 
derived from the ASCII code for A, and so on. The actual formula 
used in our algorithm is based upon a simple computation called the 
exclusive OR, which we shall describe as we go through the algorithm. 

Figure 3.1 shows the algorithm, called Algorithm E. We shall go 
through it step by step. 

Step 1. The key is a set of letters (e.g., “abracadabra”) that is the 
secret part of the encryption scheme. Anyone who knows the key can 
decipher the encrypted text. 

Step 2. The key and the block of text are stored in the ASCII code. 
Each occupies a set of contiguous bytes of memory and is terminated 
by a zero byte. (Zero is a good terminator—it corresponds to the 
ASCII nul character, which is never part of a legitimate text string.) 
The purpose of a terminator is to know when processing a string is 
completed. An alternative is to supply with each string its length in 
characters, but this is much harder to work with and far more error- 
prone than the use of terminators. 

Step 3. An index and a pointer are examples of two uses of the 
ZSOOO’s registers that we discussed in Chapter II: an index register and 
an address register. 

Step 4, Getting the character pointed to by the pointed P merely 

Algorithm for Encrypting Text 

1. Choose a key —a string of text. Let N denote the number of 
characters in it. 

2. Assume given a block of text to be encrypted. Let the text be 
stored in ASCII representation in consecutive bytes of memory 
with a zero byte signaling the end of the text. 

3. Initialize the index I to 1: initialize the pointer P to point at 
the first character to be encrypted. 

4 . Get the character pointed to by P. 

5. If the character is a zero, stop; encryption is complete. Other¬ 
wise form the exclusive OR of the character with the l-th 
character of the key. 

6* Store the encrypted character via P. 

7. Increment P by one byte address; replace I by (I mod N) + 1. 

8. Go back to step 4. 


3.1: Algorithm E 
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means using an address register to specify the desired data. 

Step 5. Testing to see whether a character is zero is a fundamental 
operation on the Z8000. The testing of this and other conditions is the 
source of all complexity and power in computer programs. 

The exclusive OR is a logical operation analogous to subtraction. In 
fact it is also sometimes called the symmetric difference. The exclusive 
OR (XOR) is defined on two one-bit operands by the following rules: 

(OXORO) = (IXORl) = 0 

(IXORO) = (OXORl) = 1 

For longer operands, the same definition is applied to corresponding 
bit positions of the two operands. Let us use the symbol -V- to denote 
the exclusive OR operation. Then, for example, F-V-3 = C; 3-V-5 = 6. 

EXERCISE 1: What is 48^0; 48^48; FO^OF? 

The exclusive OR operation obeys the following rules for any argu¬ 
ments A, B, C: 

(1) = 0 

(2) A^O = A 

(3) (A^B)A;^C = A-V(&YC) 

(4) IfB^A = C^A,thenB = C 

(5) = B^A 

The properties of the exclusive OR are interesting, but we don’t 
need to understand them to understand the algorithm and the 
subsequent programs. But if you are mathematically inclined, then 
notice that rule (4) is what makes it possible to do encryption withV: 
different letters never get coded into the same encrypted letter. Also, 
rules (1), (2) and (3) show that the way to “decrypt” our text is merely 
to encrypt it again, since (X-V-A)^A = X-V^(A-V-A) = X^O = X. 

Step 6. This is the mirror image of Step 4. The character addressed 
by the pointer P is updated with the encrypted version; in Step 4 it was 
fetched into the CPU for processing. 

Step 7. The final point that needs explanation is the mod function. 
The definition of (I mod N) is: the number between 0 and N - 1 that is 
the remainder when I is divided by N. For example, (13 mod 12) = 1; 
(6 mod 6 ) = 0;(-9mod4) = 3. 

EXERCISE 2: What is (4 mod 3)? 
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The step “replace I by (I mod N) + 1“ causes I to cycle over and 
over through the numbers 1 to N: 1, 2, . . N, 1, . . N, . . just as 
the hours digits of a clock cycle through 1,. . 12, 1,. . 12,... 

Now let’s take an example. Suppose our block of text consists of the 
ASCII characters for 

“Hi! I’maZSOOO.’’ 

and our key is 

“abracadabra” 

The text consists of the codes: 48, 69, 21, 20, 49, 27 , 6D, 20, 61, 20, 
5A, 38, 30, 30, 30, 2E, 0. The key consists of: 61, 62, 72, 61, 63, 61, 
64, 61, 62, 72, 61, 0. (See Figure 1.15.) After the application of our 
algorithm, the encrypted text consists of: 48V61, 69V62, 21-V^72, 
20V61, 49V63, 27V61, 6DV64, 20V61, 61-V62, 20V72, 5A¥61, 38¥61, 
30¥62, 30V72, 30¥61, 2E¥63,0. 


EXERCISE 3: Write out the encrypted string (i.e., perform the V-opera- 
tions). What does it look like as text? 

Figure 2 shows a Z8000 program (non-segmented) to implement 
Algorithm E. The first thing to notice is that it fits on one page. This is 
a rule of thumb that has recently become popular—a program that 
can’t fit on one page is too large and should be broken into smaller 
units. 

Next notice the large block of text at the beginning enclosed between 
two I’s and the smaller blocks of text down the right side of the pro¬ 
gram also enclosed between i’s. This material is called comments', it is 
for the convenience of the reader—the assembler program pays no 
attention to it as it translates this program into machine instructions. 

The comments give us information that is essential in relating the 
program back to Algorithm E. First, we are told where in memory the 
key and the text to be encrypted are stored. Next we are told which 
Z8000 registers are to correspond to the symbols P, I and N of the 
algorithm. Finally, each step of the algorithm is identified with a small 
group of instructions. 

In Chapter II we discussed registers, but we have not yet dealt with 
symbolic addresses for memory locations. Basically, each byte of the 
Z8000’s memory has an address: a number between 0 and 65,535 (with 
an additional segment number between 0 and 127 if the Z8000 is 
operating in segmented mode). Suppose, for example, that the key is 
“CAT” and that it is stored in memory byte locations 18, 19, lA, IB 
(3 characters plus a terminator). Then 18 contains a 43 (the ASCII 
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!Encryption Program—for algorithm E. 


Assume that the key has been chosen and is stored in memory starting at the 
address KEY, with a zero byte signaling the end. 

Assume that the text to be encrypted is stored in memory starting at location 
SECRET. 

We shall use the following register assignments. 

RO: working register 

Rl: the pointer P of the algorithm 

R2; the index I of the algorithm (kept as I - 1) 

R3: used to store N—the length of the key! 

LDA R1,KEY !Compute the length of the key! 

CALL LENGTH 

LD R3,R0 !Save the length (N)! 

LDKR2,#0 ! Step 3 of Algorithm E! 

LDA Rl,SECRET 

LOOP: LDBRL0,@R1 !Step4! 

TESTBRLO ! Step 5! 

JR Z,DONE 
XORB RL0,KEY(R2) 

LDB @R1,RL0 !Step6! 

INC Rl !Step7! 

INC R2 
CALL MOD23 

JR LOOP !Step8! 

DONE: HALT !More of step 5! 


3.2: Program for Algorithm E 

code for C), 19 contains 41, 1A contains 54 and IB contains zero (see 
Figure 1.15). Furthermore, suppose that the text to be encrypted is 
stored starting at memory byte location 20F6 and continues through 
2117. If the first few characters are “Now is the time... ” then 20F6 
contains 4E, 20F7 contains 6F, 20F8 contains 77, 20F9 contains 20, 
and so on. 

In the course of the program, the Z8000 will need to load “18” into 
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an address register when it has to deed with the key and “20F6” into 
an address register when it has to deal with the text to be encrypted. 
Many techniques have been devised to free the programmer from 
having to deal with these actual memory addresses (i.e., 18 and 20F6) 
and in general from having to “manage” the allocation of the 
available memory at this numeric level. The foremost technique is 
symbolic addresses. The comments tell us that the key is stored 
starting at address KEY, and that the text to be encrypted is stored 
starting at location SECRET. This means that somehow the symbol 
KEY has been made to correspond to the address 18 and the symbol 
SECRET to the address 20F6. We say: KEY has the value 18; SECRET 
has the value 20F6. 

There are several ways that this can be made to happen. For example, 
our program could contain the statements 

KEY = %18 
SECRET = %20F6 

(The % is used to let the assembler know that 18 is hexadecimal, not 
decimal.) This is the simplest way, but it forces the programmer to 
decide on these locations. We shall encounter automatic ways as we go 
along. The most basic one involves use of the location counter. 

As the assembler program is translating our source program, it has 
to keep track of where in memory each instruction that it assembles 
will reside; it does this by keeping a location counter. As it starts, the 
location counter contains the address of the first memory location to 
be used by the program (later we shall talk about how it finds out what 
the first location will be). Then, as each instruction is assembled, the 
number of bytes it will occupy is added to the location counter to 
obtain the address of the next instruction. Figure 3.3 illustrates the 
assembler’s use of the location counter. How the assembler decides 
the number of bytes each instruction requires and what the actual hex 
values are is the subject of Chapters IV and V. The line containing 


X: ADDR1,R2 

illustrates the way symbolic names are assigned automatically to 
memory locations. When the programmer writes this line, it is a 
command to the assembler to give X a value equal to the memory 


ELEMENTARY PROGRAMMING TECHNIQUES 57 



Location 

Counter 


Instruction 


Memory 












address at which the hexadecimal code for ADD R1,R2 is to be stored. 
As Figure 3.3 shows, the hexadecimal code for ADD R1,R2 (8121) is 
stored at location 15FC, so X gets the value 15FC. 

Of course, the question naturally arises: “Why have symbolic 
names for memory locations but not for registers?” The answer is that 
registers can be given symbolic names (with most assemblers) by state¬ 
ments of the form 


P = R1 


N = R3 


We shall do this in later chapters, but it is less confusing to use the 
register names explicitly in our early programs. 

The use of symbols in computer programs will be clarified by the 
examples as we go along. For now, we return to examining the 
program of Figure 3.2. 

The program contains 15 instructions. The first five and the last one 
are each executed only once. The other nine are the main loop. Three 
of these (LDB RL0,@R1; XORB RL0,KEY(R2); LDB @R1,RL0) 
are the essence of what the loop does. The remaining six are concerned 
with the mechanics of looping and terminating the loop. 

Loops have different structures. In this one, the test that terminates 
the loop (TESTB RLO; JR Z, DONE) is at the beginning, while up¬ 
dating of the loop parameters (P and I of Algorithm E) occurs at the 
end. This has two consequences worth noting: (1) it is possible to 
terminate the loop without ever executing it; (2) the loop parameters 
(P and 1) always have “natural” values, i.e., the values corresponding 
to the current loop iteration, but when the loop terminates, their values 
correspond to an iteration that didn’t happen. 

Now let us go through the instructions. The first three determine the 
length of the key—the parameter N of Algorithm E. The instruction 

LDAR1,KEY 

loads the address of the key into register 1. Note how different this is 
from LD R1,KEY which would load into R1 the contents of the 
memory location whose symbolic name is KEY, i.e., the first two 
characters of the key. So if KEY is as in the above example, then R1 is 
loaded with the hex value 18. 
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The instruction 


CALL LENGTH 

is an invocation of the subroutine located in memory starting at the 
location whose symbolic name is LENGTH. This subroutine doesn’t 
exist yet—we shall write it later. For now we know that we need the 
length of the key for use in our algorithm, so we write this subroutine 
call and go on. Experience tells us to require that the routine 
LENGTH take the address of a zero-terminated string in R1 and 
return its length (not counting the zero) in RO, since such a routine is 
easy to write and will be useful in other contexts. We don’t need to 
think about the details of LENGTH now while we are still working on 
our program’s overall structure. 

The instruction 


LD R3,R0 

merely moves the length of the key from RO to R3. We could have 
eliminated this instruction by having the subroutine LENGTH return 
its answer in R3, but that would have reduced LENGTH’S general use¬ 
fulness. 

The next two instructions constitute Step 3 of Algorithm E. The 
instruction 

LDK R2,#0 

loads the value 0 into R2 (remember: R2 contains I - 1). The “#” 
denotes an immediate argument. That means that the value to be 
loaded into RO (i.e., 0) is part of the instruction. LDK R2,#0 is an 
alternative to LD R2,#0; the latter does exactly the same thing but 
takes twice as much memory. LDK can be used only with values #0 to 
#15. 

Incidentally, when we write numbers in our assembly language 
programs, they are decimal numbers. When we write hexadecimal 
numbers, we precede them with “%.” For example, 15 = %F. 

The instruction 


LDARl,SECRET 

is exactly analogous to the LDA R1,KEY discussed above. It initializes 
P to point to the first character of the text to be encrypted. Using the 
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values of the example above, this means that R1 is loaded with the 
value %20F6. 

The instruction 

LOOP: LDBRL0,@R1 

introduces several new features of the assembly language. First, the 
name “LOOP” followed by indicates that the memory location 
containing the LDB R0,@R1 instruction will have the symbolic name 
LOOP. (See Figure 3.3.) That way, when we wish later in the program 
to repeat this step, we can use the instruction 

JR LOOP 

to bring us back. The “@” in LDB RL0,@R1 indicates that R1 is to 
be used as an address register; it contains the memory address of the 
byte to be loaded into the byte register RLO. RLO is the low order half 
of RO. The “B” on the end of LDB signifies a byte instruction. All 
byte instructions end in “B” except for DBJNZ, and all long-word 
instructions end in “L.” The converse is not true. For example, SUB— 
subtract—is not a byte instruction, and SLL—shift left logical—is not 
a long-word instruction. 

■ The next three instructions and the last instruction make up Step 5 
of Algorithm E. Step 5 is of the form 

IF (so-and-so) THEN DO (one thing) ELSE DO (the other) 

This is a very important form in programming, because it can be 
written in one step, eliminating a lot of unnecessary mechanical jumping 
around in our algorithm. It simplifies the flow of control, and it is 
easy to read, since we can see at once when to do “one thing” and 
when to do “the other.” 

Unfortunately, most computers do not have instructions of this 
form, so we have to render it by “mechanical jumping around.” The 
instructions 


TESTB RLO 
JR Z,DONE 

DONE: HALT 
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implement the “if the character is a zero byte, stop” portion of Step 5. 
The instruction JR Z,DONE means: if the previous operation caused 
the Z bit to be set (indicating a zero result), then begin executing at the 
instruction stored at the memory location with symbolic name “DONE.” 
The “previous operation” we are interested in is LDB RL0,@R1, 
which loads register RLO with the byte that might be zero. But, unlike 
the move instruction of the PDP-11, the load instruction does not 
change any condition bits, so the LDB RL0,@R1 must be followed by 
TESTB RLO before we can test for a zero byte. 

The “ELSE” portion of Step 5 is the instruction 

XORB RL0,KEY(R2) 

This uses the indexed addressing mode, which we shall discuss in 
Chapter V; the operand “KEY(R2)” means the byte (since XORB is a 
byte instruction) whose memory address is determined by adding the 
contents of R2 to the address whose symbolic name is KEY. That is, if 
R2 contains 0, we get the first character of the key; if R2 contains 1 we 
get the second, and so on. In other words, R2 must contain I - 1 to cor¬ 
respond to the algorithm. The entire instruction has the effect of 
forming the exclusive OR of the contents of RLO (the text character 
just fetched) and the I-th character of the key. 

There is another way to arrange the instructions of Step 5 to keep 
them all together: 


TESTB RLO 
JR NZ,NOTDONE 
HALT 

NOTDONE: XORB RL0,KEY(R2) 

This is a matter of personal preference. The original is better for 
several reasons: 

• The NZ condition is the opposite of the one stated in the algorithm; 
double negatives are hard to understand. 

• The NOTDONE label is totally artificial. There is no reason for a 
label in the middle of this loop. 

• It is clearer to have the program termination occur at the end. 

• Subsequent program modifications might introduce other termina¬ 
tion conditions. The labeled HALT instruction at the end provides 
a natural way for them to be expressed. 
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The next instruction 


LDB@R1,RL0 

implements Step 6. It is exactly the reverse of the LDB RL0,@R1 used 
to fetch the byte. Its effect is to store the encrypted byte back on top of 
(thus destroying) the original unencrypted byte. This also points out 
another slightly surprising feature of the Z8000 instruction naming. 

The original meaning of load in early computers was: transfer the 
contents of a specified location into a specified (or implied) register. 
There was always a corresponding operation called store that did the 
opposite. In these computers there were separate instructions for 
transferring from one register to another or (sometimes) from one 
memory location to another. What all of these instructions were doing 
was moving data from one place to another, and in some later machines 
(e.g., the PDP-11) they were all combined into one instruction—the 
move instruction. 

The Z80(X) load instruction is really much more like a move in¬ 
struction than it is like the traditional load. For experienced 
programmers it will take some “unlearning” to be able to think about 
loading memory from a register. 

The next two instructions implement Step 7 of Algorithm E. The 
first. 


INCRl 

causes the pointer P to point to the next byte of text to be encrypted. 
This instruction provides an example of what is called a default 
condition. In fact the full form of the instruction specifies an amount 
between 1 and 16 by which to increment. For example, if we were 
pointing at words instead of bytes, we could have written INC Rl,#2 
to cause our pointer to point to the next word. But if we write no value 
for the increment, as above, the assembler assumes the default case 
INC R1 ,#I. This is good human engineering. 

The next two instructions 

INCR2 
CALL MOD23 

implement “replace I by (I mod N) -I- 1”. But remember that, in the 
algorithm, the index I went from 1 to N, while here in the program we 
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want it to go from 0 to N - 1. Therefore, instead of starting it at 1, 
we started it at zero, and instead of (I mod N) + 1 we compute 
(I + 1) mod N. (Do you see why?) 

The INC R2 computes I -f 1, and the CALL MOD23 then gives 
(I + 1) mod N. This is because the as yet unwritten subroutine MOD23 
forms 

(contents of R2) mod (contents of R3) 
and leaves the result in R2. 

MOD23 is not likely to be a widely used subroutine. There are so 
many different ways you might want a mod routine to behave—in 
terms of where it finds its arguments and where it leaves its answers— 
that we might as well write a special purpose routine that uses the 
registers in which our program happens to have the arguments. MOD23 
will probably never be called from anywhere but right here, but we 
have made it a subroutine instead of coding it in line for four reasons: 

• The structure of the program better reflects the algorithm if these 
details are postponed to a lower level, and the program is easier to 
read and understand; 

• It is distracting to become involved in the details of a subproblem 
when you are still trying to organize the main problem; 

• The discipline of defining how the main program will talk to this 
subroutine helps to clarify the logic at both levels and to avoid 
needless entanglement of these distinct problems; 

• This organization serves to simplify and clarify the flow of control— 
thus attacking the greatest source of problems in program design 
and maintenance. 

The next instruction. 


JR LOOP 

takes us back to Step 4 (exactly what Step 8 says to do). This is the 
same kind of instruction as the JR Z,DONE used above; when no 
condition (e.g., Z) is specified, the assembler generates the form of the 
instruction that always transfers to the specified location. 

There is an important limitation of the JR instruction. This is that 
the address to which you wish to transfer must be no more than 254 
bytes before or 256 bytes after the address of the location containing 
the JR. If you follow the rule of thumb about writing programs that 
fit on one page, then this is ho problem—since there is usually no 
reason to transfer (as opposed to CALL) to any place outside your 
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program. (A location to transfer to on “fatal” errors might be an 
exception.) 

If you have to do a “distant” transfer, there is a special form of the 
JR instruction called JP, which allows you to transfer anywhere in 
memory but takes four (or even six) bytes of memory instead of the 
two used by JR. JP is also used with advanced programming tech¬ 
niques (see Figure 6.13), since it allows transfer to addresses specified 
in an address register or to a table of instructions indexed by an index 
register. 

That concludes our program—except for the two routines we left to 
be written later: LENGTH and MOD23. Now we attack these smaller 
problems. 

LENGTH is supposed to take the address of a zero-terminated 
string of bytes in R1 and return the number of non-zero bytes in RO. 
First, the straightforward way: 

LENGTH: CLR RO 
COUNTLP: TESTB @R1 

JR Z,ZERBYT 
INC RO 
INC R1 
JR COUNTLP 
ZERBYT: RET 

This illustrates the form of a subroutine. The first instruction to 
be executed bears the label to be used in calling it (e.g., we said 
CALL LENGTH in our program). The termination of the sub¬ 
routine’s operation and the return to the calling program are accom¬ 
plished with the RET instruction. 

The Z8000 supports the operation of the CALL and RET 
instructions with the stack register (see Figure 3.4). We shall call it 
SR—it is R15 in non-segmented mode or RR14 in segmented mode— 
and there are different copies of the stack register for system or normal 
modes. 

When a CALL is executed, the address of the first instruction fol¬ 
lowing the call is pushed via SR before the transfer to the subroutine is 
made. So in Figure 3.2, the address of the LD R3,R0 instruction is 
pushed, and then the transfer to LENGTH is made—when the CALL 
LENGTH instruction is executed. 

When a RET is executed, the address on top of the stack (one word 
in non-segmented mode, two words in segmented mode) is popped 


!Start counting bytes! 

!Check the next byte! 

!If it’s zero, we’re done! 

!Else, count another non-zero byte! 
!Point to the next byte! 
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CALLX 

A 




ORIGINAL STACK ON ENTRY TO X 

STACK (address of instruction 

following CALL X has 
been pushed onto stock) 


STACK BEFORE RET STACK ON 
(must be the some RETURN 

os on entry) 


The dork line shows the flow of control, i.e., the order of execution of the in¬ 
structions. 


3.4: Use of the Stack for CALL and RET 


into the PC. For this to work, of course, the top of the SR stack has to 
be exactly the same just before the RET as it was just after the CALL. 
(See Figure 3.4.) 

If no use of SR is made by the subroutine or by any subroutine it 
calls, then there should be no problem. But, as we shall see, the stack 
provides a convenient source of temporary storage; each subroutine 
that uses the stack must be sure that it does exactly as many POP’s 
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before it returns as it did PUSH’S as it went along. In fact, it is even 
more complicated than that, but in the chapter on Advanced Pro¬ 
gramming Techniques we shall see how to keep this problem under 
control. 

Looking again at our LENGTH routine, notice the symbols 
COUNTLP and ZERBYT. They are very similar in function to LOOP 
and DONE in our main program. In fact, we should have liked to call 
them by the same names, but this would have confused the assembler 
when we tried to assemble the main program and its subroutines 
together, which is the usual thing to do. 

The problem is that all of these symbols are global. So if, for example, 
we wrote JR LOOP in the LENGTH subroutine when we meant 
JR COUNTLP, the assembler would generate a transfer out of the 
LENGTH subroutine to the instruction labeled LOOP in the main 
program—with very undesirable results when the code was executed. 

We won’t go further into global symbols and local symbols now. 
Their discussion depends upon specific systems and assemblers, tools 
to be discussed further in Chapter X. 

Going back again to the LENGTH subroutine, let us examine its 
overall structure. It consists of seven instructions. The first and last 
are executed once each; the remaining five make up a loop. In the 
loop, two instructions (TESTB @R1 and INC RO) are what the loop 
does, and the other three are concerned with looping and terminating 
the loop. 

The CLR RO instruction, which is new to us, is simply an alter¬ 
native to LDK R0,#0. Also, unlike LDK, it can be used with an index 
or address register or with the direct addressing mode, which allows 
access to any memory location. 

Notice that in the loop, we might have wanted to place the INC R1 
instruction directly after the TESTB @R1 to make it clear exactly 
what R1 was for and how we were using it. Unfortunately, this would 
affect the condition bits so that the JR Z,ZERBYT would no longer 
be testing the state of the byte pointed to by Rl. A way around this 
would be provided if the INC Rl could actually be combined with the 
TESTB @R1—a new addressing mode that fetched via a pointer and 
then incremented the pointer so it was always ready for the next fetch. 

There is such an addressing mode, called autoincrement, but it isn’t 
available with the TEST instruction. In fact, autoincrement, and its 
cousin autodecrement, are available only with a group of instructions 
called the block transfer and string manipulation instructions (and 
implicitly in PUSH, POP, etc.). 
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Every computer is designed to do some things particularly well. 
When writing a routine like LENGTH, which is potentially generally 
useful, it is good to look for features of the computer that might 
optimize frequently executed blocks of code—like the loop in 
LENGTH. 

TEST does not have any relatives in the block transfer and string 
manipulation group, but a very similar instruction called CP (compare) 
does have a block version. The relationship between CP and TEST is 
simple: TESTS @R1 is (almost) the same as CPB @R1,#0, that is, 
testing something is the same as comparing it to zero. 

Now the block compare instruction that looks most promising is 
CPIRB (compare, increment and repeat—byte), but it wasn’t exactly 
designed for our case. It lets you scan a string, testing each byte by 
comparing it with a register, and continuing byte-by-byte until a 
certain condition is met or until a preset number of bytes have been 
tested. That is, it is designed for the case in which you know the length 
of the string but not whether the condition will ever be satisfied. Our 
case is the opposite—we don’t know the length of the string, but we 
know that it has a zero at the end. 

With this preamble, here is LENGTH—second version: 

LENGTH: CLR RO ! Count bytes in RO! 

CLRB RL2 !Look for zero byte! 

CPIRB RL2,@R1,R0,EQ IScantothezero! 

INC RO ICompensate for zero byte! 

NEGRO ! CPIRB counts backwards! 

RET 


This program illustrates an interesting phenomenon: it is very short 
(six lines), control passes in a direct line from first instruction to last, 
there is a helpful comment on each non-obvious line, and it has been 
preceded by a good deal of commentary—yet it is almost totally in¬ 
comprehensible. You cannot understand this program without 
staring at it for a while, and no comments or external “documentation” 
will change that fact. 

The CPIRB RL2,@RI,R0,EQ instruction works like this: 

(1) Compare the byte pointed to by R1 to the zero byte in RL2. 

(2) Increment R1 by 1 to point at the next byte. 

(3) Decrement RO by 1 (since RO started at zero, RO will have - 1 
the first time, - 2 the second, and so on). 
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(4) If RO is zero (it never will be unless we have a very long string) 
or if the result of the comparison in step one was equality 
(i.e., it was the terminating byte), the instruction is finished; 
otherwise go back to step (1). 

The reason for the INC RO instruction is that RO gets decremented 
when the zero byte is found, but we only want to count non-zero 
bytes. 

EXERCISE 4: We could have written NEC RO; DEC RO instead of 
INC RO; NEC RO. Why are they the same? Which is clearer to the reader? 

Now let us compare our two versions of LENGTH for memory 
space used and execution time. In the next chapter we shall learn how 
to determine the number of bytes of memory and the number of clock 
cycles of execution time required by each instruction. Figure 3.6 shows 
this analysis for the bodies of our two LENGTH routines. In neither 



Bytes 

Cycles 

CLR RO 

2 

7 

TESTB @R1 

2 

8*(L+1) 

JR Z,ZERBYT 

2 

6*(L+1) 

INC RO 

2 

4*L 

INC R1 

2 

4*L 

JR COUNTLP 

2 

6*L 


12 

21+28*L 

CLR RO 

2 

7 

CLRBRL2 

2 

7 

CPIRB RL2,@R1,R0,EQ 4 

11+9*(L+1) 

INC RO 

2 

4 

NEC RO 

2 

7 


12 

L = #of non-zero bytes in the string. 

45 + 9*L 


3.6: Comparison of Two Versions of LENGTH 
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case is the CALL or the RET instruction taken into account. The 
constant L represents the number of non-zero bytes in the string. 
The two routines take identical amounts of memory space. Our first 
(straightforward) version is faster for strings of length zero or one; for 
any values of L greater than one, the second version is much faster. 

EXERCISE 5: How many clock cycles would each version take for the key 
“abracadabra”? How many microseconds if the clock runs at the maxi¬ 
mum rate of 4 MHz (250 ns per cycle)? 


Our second version of LENGTH has the side effect of changing 
registers R1 and R2. This is undesirable if LENGTH is to be a general 
purpose routine. To avoid this we can use the stack to save the values 
of these registers as we enter and to restore them just before we leave. 
The final version of LENGTH, incorporating this change, appears in 
Figure 3.7. 


!Length computing subroutine 


CALL LENGTH; R1 = adr of zero-terminated string. 

Returns RO = # of non-zero bytes in the string—all other registers unchanged. 

Register assignments: 

RO: counts non-zero bytes 

Rl: pointer to string 

R2: RL2 keeps zero byte for compare instruction! 

LENGTH: PUSH @SR,R1 

PUSH @SR,R2 

ISave registers! 

CLR RO 

CLRB RL2 

CPIRBRL2,(g)Rl,R0,EQ 

NEG RO 

DEC RO 

!Count bytes in RO! 

!Zero byte for comparison! 

!Scan to the zero! 

!CPIRB counts backwards! 

!Don’t count the zero byte! 

POP R2,(g)SR 

POP RL@SR 

!Restore registers! 

RET 



3.7: LENGTH Subroutine for the Encryption Program 
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EXERCISE 6: 

(a) The additional PUSH’S and POP’s add 34 cycles to the routine’s 
execution time. How many non-zero bytes must a string contain before 
this version is faster than the first (straightforward) version? 

(b) The POP’s at the end are in the opposite order to the PUSH’S at the 
beginning. Does this matter? 

(c) We could reduce execution time by 10 cycles if we started with 
PUSHL @SR,RR0 and ended with POPE RR0,@SR. Is the effect the 
same? Which is clearer? 


We come now to the subroutine MOD23 which computes 

(contents of R2) mod (contents of R3) 

and leaves the result in R2. Figure 3.8 shows this subroutine. The new 
elements in it are the SRLL and DIV instructions. 

The heart of the MOD 23 routine is the instruction 

DIV RR2,R4 


This causes the 32-bit value stored in the long-word register RR2 


! MOD23 Subroutine 


CALL MOD23; R2 contains I 


R3 contains N ^ 0 


Returns with (I mod N) in R2, other registers unchanged. 

Register assignments: 


RR2: Long-word version of dividend 

R4; Temporarily contains divisor (N)! 

MOD23: PUSH @SR,R4 

ISave contents of temp register! 

LD R4,R3 

1 Divisor goes to R4! 

SRLL RR2,^16 

IMove I to low order position! 

DIV RR2,R4 

!(I mod N) to R2; quotient to R3! 

LD R3,R4 

!Move N back to R3! 

POP R4,@SR 

!Restore temp register! 

RET 



3.8: MOD23 Subroutine for the Encryption Program 
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(consisting of high order R2 and low order R3) to be divided by the 16- 
bit value in R4. The quotient is left in R3 and the remainder in R2. 

Because this is the mod function, we are only interested in the 
remainder—which happens to be left exactly where we want it. The 
divisor, N, has to be moved out of the way into R4 for the division 
then back to R3 after the division, because that is where the routine is 
supposed to leave it. The push and pop of R4 are there to prevent the 
routine from having any side effects on the registers. 

The instruction 


SRLL RR2,#16 

is designed to convert the 16-bit value in R2 to a 32-bit value in RR2 
with a high order word of zero. It is a logical right shift of the long 
register RR2 by 16 bits. 

The Z8(XX) is provided with a number of left and right arithmetic 
and logical shifts and rotations operating on bytes, words or long- 
words, or on combinations of any of these with the C status bit. The 
general idea is that each bit moves a specified number of places (16 in 
the above example) to the right or to the left; they differ in what 
happens at the ends. This is explained in detail in the next chapter. In 
our case (a logical right shift), bits shifted off the right end are lost, 
and vacated positions on the left end are filled with zeros. Therefore, 
SRLL RR2,#16 is equivalent to 

LD R3,R2 
CLR R2 

We began our encryption program as a main program, i.e., one that 
is not a subroutine of any other program. In fact, it will be more 
useful if it can be called as a subroutine, so we finish the example by 
presenting, without much comment, a subroutine version of the 
encryption program. 

Figure 3.9 shows this routine. Notice the changes that have been 
made. First, the registers have been saved and restored using the LDM 
(load multiple) command, which is designed to move contiguously 
numbered blocks of registers into contiguous memory locations. 

EXERCISE 7: Why the difference between the 10 in the INC and DEC 
instructions and the 5 in the LDM? 
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lEncryption Subroutine—following Algorithm E. 

CALL ENCRYPT; RO = address of text 

R1 = address of key 

(text and key are 0-terminated strings) 

Returns with text replaced by encrypted text, registers unchanged. 

Register assignments 


RO (RLO & RHO): Working registers 

Rl: Address of key 


R2: Index 1 to position in key (0<1< N) 

R3: N (length of key) 


R4: Address of text to be encrypted! 

ENCRYPT: DEC SR,#10 

ISave RO thru R4 on SR stack! 

LDM @SR,R0,#5 


LD R4,R0 

!Pointer to text! 

CALL LENGTH 

! Compute N! 

LD R3,R0 


CLR R2 

!Initialize I! 

LOOP: LDB RL0,@R4 

!Next byte of text! 

TESTB RLO 

!0 terminates! 

JR Z,DONE 


LDB RH0,R1(R2) 

!I-th byte of key! 

XORB RLO,RHO 

!Encrypt text! 

LDB @R4,RL0 

!Replace text, point to next! 

INC R4 


INC R2 

! Replace I by (I + l)modN! 

CALL MOD23 


JR LOOP 


DONE: LDM R0,@SR,#5 

!Restore registers! 

INC SR,#10 


RET 



3.9: Subroutine Version of the Encryption Program 
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Second, notice the instruction 


LDB RH0,R1(R2) 

This is the base indexed addressing mode—one of the outstanding 
features of the Z8000 design. Unfortunately it is not available with the 
XOR instruction—or we could have written 

XORB RL0,R1(R2) 
without the intermediate step of loading RHO. 

EXERCISE 8: What other changes do you notice? Can you explain them? 

This concludes our example. We have taken the encryption problem 
from its initial statement to a complete final program. In the course of 
doing this we have used many of the ZSOOO’s instructions and address¬ 
ing modes. The next two chapters will present all of the instructions 
tions and addressing modes in a more organized way. 
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Chapter IV 
Z8000 Instruction Set 


PARTI 

In the two preceding chapters we discussed the Z8000 architecture 
and began to explore ways to use it. In this chapter and Chapter V we 
make a systematic presentation of the instructions and addressing 
modes. The heart of this material will be the 45 instruction descriptions 
that make up Part 2 of this chapter; these are the fundamental reference 
for the operation and format of ZSOOO instructions. We begin with an 
overview. 

We group the ZSOOO instructions into eight categories. This will 
oversimplify, since some instructions don’t fall cleanly into one cate¬ 
gory, and the number of categories could be larger or smaller. The 
categories chosen for this presentation are: 

(1) Data Operations and Testing 

(2) Data Transfers 

(3) Pointer Setting 

(4) Transfer of Control 

(5) Input/Output 

(6) CPU Control 

(7) Block Operations 

(8) Multi-Micro Synchronization 

As we discuss these categories we shall list the instructions that 
comprise them. The instruction mnemonics are listed with optional 
variations enclosed in parentheses. For example, ADC(B) represents 
ADC and ADCB; (g)I represents DI and El. In general, when one 
letter is in parentheses, that letter appears in some versions of the 
instruction but not in others (e.g., ADC, ADCB). When two or more 
letters appear in parentheses, then one of these letters appears in any 
given version (e.g., DI, El). The one exception to this is C®), for which 


75 



B, L or neither may appear. So LD(®) represents LD, LDB and LDL; 
R(^)(C)(B) represents RL, RLB, RLC, RLCB, RR, RRB, RRC, RRCB. 
This simple shorthand allows us to treat the many possible variations 
of some instructions in a unified way. We shall be using this notation 
extensively throughout this chapter. You should be sure you under¬ 
stand it. 

Data Operations and Testing 

This category consists of the instructions that modify or test the 
values of their arguments; they are the only ones for which the FLAGS 
bits are set to reflect their outcome. (The block operations and the 
multi-micro synchronization instructions use FLAGS bits in special 
ways, and some instructions allow them to be manipulated explicitly 
or change them as a result of changing the CPU status.) 

{di) Arithmetic instructions: ADD(®), SUB (®), MULT(L), DIV(L), 
ADC(B), SBC(B), NEG(B), DAB. These implement the usual arith¬ 
metic operations of addition, subtraction, multiplication and division. 
They are the only instructions in this category that use C to reflect 
their result. On the Z8000, C is used primarily to allow implementation 
of multiple-precision versions of the arithmetic instructions. 

(b) Logical instructions: AND(B), OR(B), XOR(B), COM(B). The 
operation of AND, OR, XOR and COM on single-bit arguments is 
shown in the “truth tables” of Figure 4.2. For 8-bit or 16-bit arguments, 
each bit position is handled independently using the single-bit rules. 
For example, 

(IIOOIIIO2 ANDB OIIOOIOI2) = OIOOOIOO2 

AND, OR and XOR are two-argument operators; COM operates on 
a single argument. The byte versions of these instructions (and TESTB) 
are the only ones using P to report the parity of the result. 

The illustrations in Figure 4.1 show schematically how the arithmetic, 
logical and shift/rotate instructions work on their operands inside the 
CPU. Every CPU has circuits for performing arithmetic and logical 
operations; these circuits are usually referred to collectively as the 
arithmetic and logical unit (ALU). 

For ADD, SUB, etc., the ALU takes three inputs: the FLAGS register, 
the source operand (either from memory or from a register) and the 
destination register. The result goes back to the destination register, 
and new FLAGS values are set. 
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Data Path for ADD, SUB, MULT, DIV, AND, OR, XOR, shift, rotate; and for 
ADC, SBC, digit rotate (register sources only) 



Data Path for NEG and COM; and for DAB (register only) 


4.1: Data Paths for Arithmetic, Logical and Shift/Rotate 
Instructions 

We shall use similar illustrations, sometimes without further com¬ 
ment, for all of the categories of instructions that we have established 
for the Z8000. 

(c) Shift/Rotate instructions: R(^)(C)(B), S(l )(l)(l)» R(r)E>B. 
These instructions allow the bits of a register to be moved left or right 
or in a circle. Figure 4.3 illustrates this. 
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AND OR XOR COM 

4.2: Truth Tables for Logical Operations 

The rotations are by one or two places and can include or exclude C 
(although C is still shifted into, even if excluded from the rotation). 

The shifts are by any amount from zero to the number of bits in the 
argument. The shift count can be specified implicitly in the instruction 
or can be taken from a register at execution time. 

The R(^)DB is a specialized instruction for moving digits in a circle 
touching two byte registers. Figure 4.4 illustrates this. 

(d) Counter/Pointer varying instructions: DEC(B), INC(B). These 
allow their arguments to be incremented or decremented by an 
amount ranging from 1 to 16; they differ from the corresponding 
add and subtract instructions in that C is unaffected and V is handled 
differently. 

(e) Testing instructions: BIT(B), CP(®), TEST(®), TSET(B). These 
instructions set FLAGS bits after examination of, rather than opera¬ 
tion on, their arguments. BIT(B) allows any single bit of its 8-bit or 
16-bit argument to be examined and sets Z to reflect its value. The 
number of the bit to be examined can be contained in the instruction 
or can be taken from a register at execution time. 

CP(®) is the basic comparison instruction, and TEST(®) can al¬ 
most be regarded as the special case of CP(®) for which one of the 
arguments being compared is zero. The idea is that sequences of code 
like 


CP X,Y; JR GT,ABC 
TEST X; RET MI 

will have mnemonic value. The above two lines mean 
“if x>y then go to ABC” 

“if x<0 thenRETurn” 
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A Rotation Left, including C, of a 16-bit register 



A Rotation Right, not including C, of an 8-bit register 




arithmetic, upon the original value of the leftmost bit. 


4.3: Some Shifts and Rotations 













4.4: The Circle of Digits for R(p)DB 

This is accomplished by assigning mnemonic codes like GT, LT, PL, 
MI, etc., to various combinations of FLAGS bits. There are 16 such 
combinations, and these can be specified in a 4-bit field present in the 
conditional instructions (TCC(B), JP, JR, RET) and the block com¬ 
pare CP(S)(^(R)(B). These mnemonic names will appear a little later 
in this chapter. For now remember that if CP x,y is written, then x 
appears on the left of the relation defined by the mnemonic ( > in the 
case above) and y appears on the right. For TEST x, the x appears on 
the left and zero appears on the right. 

The TSET instruction could have been placed in a category by itself, 
since it combines a test and a data transfer. The idea is to test a flag 
and simultaneously change its value to the “harmless” state; this pro- 



4.5: Data Paths for Counter/Pointer Varyinji Instructions 
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BIT TSET 

4.6: Data Paths for Testing Instructions 

tects against two “simultaneous” positive tests of the flag by pro¬ 
cesses running concurrently. TSET is designed to facilitate the use of 
semaphores, a computer science technique arising out of the study of 
concurrent processes. 

Data Transfers 

This category consists of instructions that move a value from one 
place to. another; the value moved can be contained in or implied by 
the instruction, or its location can be an argument of the instruction. 
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The original contents of the destination of the transfer are irrelevant 
and are lost (except for EX(B)). 

The data transfer instructions leave all FLAGS bits unaffected. 

(a) Constant transfer instructions: CLR(B), LDK, RES(B), SET(B), 
TCC(B). These instructions move a fixed value specified in the instruc¬ 
tion into the destination location. CLR(B) sets the destination value to 
zero. LDK contains a 4-bit field to allow setting the destination to a 
value in the range 0 to 15. RES(B) and SET(B) allow a specified bit to 


Destination Argument 


Zero 


CPU 


CLR 



SELRESJCC 


4.7 (a): Data Paths for Data Transfers and Pointer Setting 
instructions—Some Constant Transfers 
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be set to zero or one; as with BIT(B), the number of the bit can be con¬ 
tained in the instruction or be taken from a register. 

TCC(B) is a conditional SET(B) instruction. The bit number is al¬ 
ways zero, i.e., only the low order bit of the argument is affected. It 
is important not to confuse this conditional transfer with the way that 
the FLAGS bits are set. All instructions that use a FLAGS bit to report 
a condition either set the bit to report the condition or clear the bit to 
report the opposite; TCC(B) sets a bit if the specified combination of 
FLAGS bits is true and does nothing if the combination is false. 

(b) Variable transfer instructions: LD(®), LDR(®), LDM, EX(B), 
EXTS(®). These instructions move the value found in their source 
argument into their destination argument. LD(®) is the basic data- 
moving instruction. It uses all of the addressing modes that the ZSOOO 
has for addressing data or stack memory. Only LD(®) and LDA can 
use the based and base indexed addressing modes. 

LDR(®) is the only instruction that allows access to program mem¬ 
ory. It uses addressing relative to the PC, and the offset from the PC 
is stored in the instruction. That means that there is no convenient way 
to have arrays or tables as part of the program, unless the memory they 
occupy is also (possibly with a different set of addresses) part of data 
memory. The only alternative is to simulate an indexed addressing 
scheme and store the resulting PC offset value into the offset field of 
an LDR(®) instruction; this requires being able to write into the pro¬ 
gram memory. In any event, LDR(®) will not allow references outside 
of the current segment. 

The LDM instruction allows from 1 to 16 registers to be loaded from 
or to memory with a single command. This is designed to facilitate 
rapid context switching in a multiprogramming environment. It is also 
useful in register saves and restores by subroutines and interrupt routines. 

The EX(B) instruction allows memory and register contents to be 
exchanged (swapped). The EXTS(®) instruction allows an argument 
in a register to be expanded to occupy a larger register (with no change 
in value) by propagating the sign bit of the original value throughout 
the additional register space. 

(c) Stack transfer instructions: POP(L), PUSH(L). These are the 
pop and push operations described in Chapter 11. (See Figure 2.2.) 
Because the hardware stack (controlled by R15 or RR14) must always 
be ready for the 16-bit operations associated with interrupts and sub¬ 
routine calls, there are no byte versions of POP and PUSH. This makes 
it difficult to save and restore the byte registers RHO, RLO,.... 
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CPU 


EXTS 

4.7 (c): Data Paths for Data Transfers and Pointer Setting 
Instructions—Sign Extension 





Source 

- 

Destination 



PUSH 


Source 


Destination 


Stock Pointer 


I _ CPU 

POP 

4.7 (d): Data Paths for Data Transfers and Pointer Setting 
Instructions—Stack Transfers 
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Pointer Setting 

There are two instructions that load an address register with the 
address of their argument: LDA and LDAR. These instructions allow 
segmented addresses to be loaded in a single operation, and they provide 
for a uniform approach that works with either segmented or non- 
segmented addresses. 

Since addresses do not depend upon the size of the arguments stored 
there, LDA X or LDAR X can be used to obtain the address of X, 
regardless of whether X is a byte, a word or a long-word. The size of 
the address register used depends upon whether the CPU is operating 
in the segmented or non-segmented mode—this information is not 
contained in the instruction. 

Since these are internal operations that do not depend for their 
operation on the status output lines from the chip, they do not dis¬ 
tinguish between addresses in program, data or stack space. 

The pointer-setting instructions do not affect any FLAGS bits. 

Transfer of Control 

This category consists of instructions that break the flow of control; 
they change the value of the PC. Except for the saving and restoring 
of CPU status associated with interrupts, none affect FLAGS. 

(a) Jumps: JR, IP, D(B)JNZ. 

(b) Subroutine instructions: CALL, CALR, RET. These are the 
instructions used for implementing subroutines. CALL and CALR 
save the return address on the stack (using R15 or RR14) and RET 
pops it back into the PC. (See Figure 3.4.) CALR is a one-word form 
of the CALL instruction that uses PC-relative addresses in a range of 
4096 words centered (approximately) on the CALR instruction. 

RET allows the use of a condition code field (described above under 
“Testing Instructions”)* This can be convenient when the return from 
a subroutine occurs inside a loop, but it should be used sparingly where 
it gives rise to subroutines containing more than one RET instruction. 
Such routines can be difficult to understand and to alter. 

(c) Interrupt/trap instructions: SC, IRET. SC is the “system call” 
trap. It causes the PC to be saved on the stack, like CALL, but the 
FCW and the “reason” (a copy of the SC instruction, one byte of 
which is an index to a table of system routines) are also pushed onto 
the stack. IRET undoes all of that, restoring the FCW and PC and 
discarding the “reason.” (See Figures 2.8 and 2.9.) 
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There are no explicit instructions to generate external interrupts or 
error traps. Interrupts and error traps cause CPU status and a “reason” 
to be saved just as for SC, and they use IRET for a return. 

Since IRET restores the status saved for the SC or other interrupt 
or trap, the net effect is no change to the FLAGS bits. An exception 
to this might be a system routine that modified the copy of FLAGS 
on the stack so as to return information to the caller. In Chapter IX 
we shall go into more detail on passing parameters to and from system 
routines called using SC. 

There are two other points of interest with respect to traps: there is 
a reserved trap that can be used if you don’t need to guarantee com¬ 
patibility with future Z8000 versions; and there are some error traps 
that would be very useful but don’t exist. The reserved trap is the “un¬ 
implemented instruction trap” that occurs when any of 6 combinations 
of mode and opcode fields are used. (We discuss mode and opcode 
fields later in this chapter.) Each of these 6 instructions could be used 
exactly as SC is used—giving six more groups of 256 system routines 
each. 

Many possible error traps might be useful, but two particularly 
troublesome omissions have to do with type mismatches: using a word 
or long-word instruction with an odd address and using a multiple-word 
register number other than the legal ones. For example, the instruction 
LD R0,@R1 requires that the contents of R1 be even; if they happen 
to be odd, the behavior of the Z8000 is undefined. There’s no telling 
what it will do, but it might ignore the erroneous low order bits of 
addresses, not looking at any it expects to be zero. This is such a serious 
drawback that it should be changed in later versions of the Z8000. The 
PSA format could be altered, or an existing trap could be shared, allow¬ 
ing the “reason” to distinguish between this and its earlier meaning. 
Meanwhile, the user should implement such a trap using the B/W and 
ADo outputs of the CPU to generate a non-maskable interrupt. This 
scheme has three main drawbacks: (1) it catches the word/byte mismatch 
but not the register mismatch; (2) it cannot catch transfers to odd 
addresses, since the PC does not latch bit zero, i.e., bit zero of the PC 
is always zero, regardless of what the CPU tries to store there; and 
(3) it causes an interrupt after the instruction has completed its undefined 
action. (See Figure 9.14.) 

Input/Output 

The Z80(X) recognizes an address space of 65,536 bytes for its I/O 
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operations and another address space of the same size for its “special” 
I/O. The special I/O operations are designed for use with the MMU, 
which cannot have address/data lines AD7-AD0 available to it. In¬ 
ternally there is no difference between ordinary and special I/O. 

The I/O instruction is very similar to the load instruction, but it is 
much more restricted in address modes. Except for the block I/O in¬ 
struction, to be discussed later, all I/O is between a CPU register and 
an I/O address specified in the instruction or contained in a register. 
No indexing of I/O addresses is possible. 

The basic I/O instruction, (S)(Q^yj)(B), does not affect any FLAGS 
bits. It is a privileged instruction. 

CPU Control 

This category of instructions has more to do with CPU housekeep¬ 
ing than with computing. FLAGS bits are only affected explicitly. 

(a) Control register manipulation: (g)I, LDPS, LDCTL. These 
instructions allow access to the control registers of the CPU. (g)I 
allows any combination of the two maskable interrupts to be disabled 
(masked) or enabled (unmasked). LDPS loads the FCW and PC from 
data memory. LDCTL is a load instruction for the four control registers: 
FCW, PSAP, NSP and REFRESH. It allows transfer between any 
one of these and a register. 

All of these are privileged instructions. 

(h) FLAGS manipulation: COMFLG, RESFLG, SETFLG, LDCTLB. 
The first three allow operating on any combination of the bits C, Z, S, 
V/P. LDCTLB is a load instruction for the entire FLAGS register. 

(c) External synchronization: HALT, NOP. The HALT instruction 
is more like a WAIT instruction than it is like the traditional HALT. 
It causes CPU operation to be suspended until an interrupt occurs—the 
IRET causes the program to resume at the instruction following the 
HALT. Also, vital functions like refresh cycles and the bus grant pro¬ 
tocol continue while the CPU is HALTed. 

NOP causes the CPU to “do nothing” for its duration (seven cycles). 
HALT is a privileged instruction. NOP is not. 

Block Operations 

There are four block operations. Three are block versions of some 
of the above instructions; one has no counterpart above. 

The general form of a block operation instruction requires a counter 
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register and two pointer registers. The execution of the instruction 
causes the counter register to be decremented and one or both of the 
pointer registers to be either incremented or decremented. The instruc¬ 
tion can be placed in a loop with other operations, or it can be repeated 
automatically until the counter goes to zero or (in some cases) some 
other condition is met. All of the block instructions can be interrupted 
between repetitions at a cost of seven cycles of overhead per interrupt. 
No other Z8(XX) instructions can be interrupted. 

All of the block instructions use V to indicate that the counter has 
gone to zero. They all either use Z or leave it in an undefined state. 

Figure 4.9 shows the three registers and the sequence of operations 
for the block versions of CP, LD and the I/O instructions. 

(a) Block data testing: CP(S)(^)(R)(B). A string of data words or 
bytes is compared either with another string or with a value in a register. 
A condition code field in the instruction allows specification of the 
combination of FLAGS bits being searched for. Z is set if there is a 
match. In the repeat mode, the instruction repeats until V or Z is true. 
C is left undefined. 

(b) Block data transfer: LD(^)(R)(B). The string of words or bytes 
is moved from one place to another. Proper choice between auto¬ 
increment and autodecrement modes is important if the strings overlap. 


Counter Register 


Source Pointer Register 


Destination Pointer Register 


(a) Operation is performed, using Source and Destination pointers. 

(b) Counter is decremented; V is set if it gets to zero. 

(c) Pointers are incremented or decremented, as required by instruction (for I/O, 
the pointer containing the I/O address is not changed). 

(d) If repeat is specified 

And if V = 0 (counter did not reach zero) 

(And if Z = 0 for CP—match did not occur) 

Then go back to Step (a). 


4.9: Registers and Operation Sequence for Block CP, LD, I/O 
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(c) Block I/O: (S)(o‘^T.)('j’)(R)(B). A string of words or bytes from 
memory are output to or input from a constant I/O address specified 
in a register. 

(d) Block translate and test: TR(T)(^)(R)B. This instruction uses 
a 256-byte translation table; the translation of any value i for 0 < i < 
255 is the i-th byte of the translation table. 



4.10: Operation of the Translate and Test Instruction 
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A string of bytes is translated using a translation table whose ad¬ 
dress is kept in a register. Each translated value either replaces the 
original value or is moved to a dedicated register (RHl) and tested to 
see whether or not it is zero. With the repeat option, the instruction is 
repeated until the count is exhausted or (with the test option) a non¬ 
zero translated value is found. (See Figure 4.10.) 

Multi-Micro Synchronization 

This category of instructions deals with synchronization of access 
to a shared resource by several CPU’s. There are two CPU pins (one 
input, one output) and a 4-bit external bus provided in the system ar¬ 
chitecture. MREQ conducts the protocol associated with this scheme. 
It uses Z and S in a special way to report its success or failure in gain¬ 
ing control of the shared resource. MBIT tests the input pin and 
reports its state using S and Z; MRES and MSET control the output pin 
and leave FLAGS bits unchanged. 

These are all privileged instructions. 

This concludes our overview of the Z8000 instruction set. Figure 
4.11 summarizes the grouping into categories. 

Condition Codes 

In the preceding sections of this chapter we alluded to 16 combina¬ 
tions of condition codes that could be encoded into a 4-bit field in 
some of the conditional instructions. 

The 16 combinations consist of eight basic conditions and their op¬ 
posites. In the 4-bit encoding, the high order bit is used as the “oppo¬ 
site” bit. For example, if 1 encodes “less than,” then 9 encodes 
“greater than or equal to.” 

Of the eight basic conditions, four are the single-bit conditions 
C = 1,Z = 1,S = 1,V/P = 1 and one is the “always false” 
condition. The remaining three are combinations: 

less than (LT): S = 1 or V = 1, but not both 
less than or equal to (LE): the above, or Z = 1 
unsigned less than or equal to (ULT): C = 1 or Z = 1. 

The naming of the conditions is designed to have mnemonic value 
when used with the compare instruction. CP x,y sets the FLAGS bits 
according to the result of the subtraction x - y; x is less than y if and 
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1. Data Operations and Testing (standard FLAGS use). 

(a) Arithmetic; ADD(®), SUB(®), MULT(L), DIV(L), ADC(B), SBC(B), 
NEG(B), DAB 

(b) Logical: AND(B), OR(B), XOR(B), COM(B) 

(c) Shift/Rotate: R(^)(C)(B), S(L)(^)(®), R(^)DB 

(d) Counter/Pointer Varying: DEC(B), INC(B) 

(e) Testing: BIT(B), CP(“), TEST(®), TSET(B) 

2. Data Transfers (FLAGS bits unaffected). 

(a) Constant transfers: CLR(B), LDK, RES(B), SET(B), TCC(B) 

(b) Variable transfers: LD(® ), LDR(®), LDM, EX(B), EXTS(® ) 

(c) Stack transfers: POP(L), PUSH(L) 

3. Pointer Setting (FLAGS bits unaffected): LDA, LDAR. 

4. Transfer of Control (FLAGS bits unaffected, except for save/restore). 

(a) Jumps: JR, JP, D(B)JNZ 

(b) Subroutine: CALL, CALR, RET 

(c) Interrupt/Trap: SC, IRET* 

5. Input/Output (FLAGS bits unaffected): (S)(Qyj )(B)*. 

6. CPU Control (FLAGS affected only explicitly). 

(a) Control Register manipulation: (g)!*^ LDPS*, LDCTL* 

(b) FLAGS manipulation: COMFLG, RESFLG, SETFLG, LDCTLB 

(c) External sync: HALT*, NOP 

7. Block Operations (special Z and V use). 

(a) Data Testing: CP(S)(°)(RKB) 

(b) Data Transfer: LD( ® )(R)(B) 

(c) I/O: (S)( )(®)(R)(B)* 

(d) Translate and test: TR(T)( ^ )(R)(B) 

8. Multi-micro Sync (special Z and S use): MREQ*, MBIT*, MRES*, MSET*. 

♦Privileged.__ 

4.11: Functional Instruction Categories 
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only if X - y is negative. If there is no arithmetic overflow, this is the 
same as S = 1. If there is arithmetic overflow, this is the same as 
S = 0. 

Similarly x = y if and only if x - y = 0, so the condition Z = 1 
is called equal, and Z = 1 combined with the condition for less than 
gives less than or equal to. 

Unsigned less than arises from regarding x and y as numbers in the 
range 0 to 2" - 1 instead of in the range - 2" ' to 2" > - 1. For exam¬ 
ple, they might be memory addresses. When the subtraction x - y is 
performed, C is set if and only if there is no carry in the addition x -(- 
(— y)- This is the case if and only if x < y, where x and y are regarded 
as unsigned. (Actually, if y is zero, there is no carry in the addition x 
+ (-y). but there is a carry in the negation NEG(y), so C is not set 
for the subtraction x - y.) In other words, x ULT y if and only if 
C = 1 after CP x,y. 

Figure 4.12 shows the 16 condition code settings, their meanings 
and their assembler mnemonics. 


CONDITION 
CODE (Hex) 

MEANING 

MNEMONICS 

CONDITION 

CODE (Hex) MEANING MNEMONICS 

0 

False 

none 

8 

True 

blank* 

1 

SXORV = 1 

LT 

9 

SXORV = 

0 GE 

2 

LTORZ = 1 

LE 

A 

LTORZ = 

0 GT 

3 

CORZ = 1 

ULE 

B 

CORZ = 

0 UGT 

4 

V/P = 1 

OV,PE 

C 

V/P = 0 

NOV,PO 

5 

S = 1 

Ml 

D 

o 

II 

CO 

PL 

6 

Z = 1 

Z,EQ 

E 

Z = 0 

NZ,NE 

7 

C = 1 

QUIT 

F 

C = 0 

NC,UGE 


‘default case (e.g., JR X gets 8 in cc field) 


4.12: Condition Codes 


Instruction Formats 

Ideally you should interact with your computer at a level no lower 
than the assembler mnemonics. The actual hexadecimal encodings of 
the instructions should be irrelevant. But, realistically, there are sev¬ 
eral reasons why this just isn’t so: 

• Different instructions take different amounts of memory. Some¬ 
times space is at a premium, and exact information about for¬ 
mats is helpful. 
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• Often the only debugging tools available are hexadecimal debug¬ 
gers (or worse). 

• Sometimes you need to construct a “patch”—a replacement for 
a certain part of the assembled program. It may even be neces¬ 
sary to create the exact hexadecimal form of the patch without 
recourse to an assembler. 

• Occasionally you have to “disassemble” manually a piece of 
hexadecimal program for which no source listing is available. 

Furthermore, knowledge of instruction formats gives a good 
framework for presenting or understanding the various aspects of in¬ 
structions. 

The Z8000 instructions follow a fairly simple pattern: all instruc¬ 
tions consist of one or two words of instruction followed by one or 
two words of address or implicit argument. In general, the first byte 
of the first word of the instruction determines which instruction it is 
and which addressing modes it uses. The remaining bytes specify 
arguments and variations. 

If the first two bits of the instruction are ones, then it is one of four 
special instructions. These are designed to accomplish frequently used 
functions in one word, without additional address or implicit argu¬ 
ment. For these four, the first hex digit determines which instruction 
it is, and the remaining twelve bits encode the desired function. Figure 
4.14 shows these four instructions. The first is a one-word immediate 
load of an eight-bit value into a byte register; the next three are 
transfers to locations addressed by small displacements from the PC. 
Since all instructions start on even byte addresses, the displacements 
are interpreted as numbers of words: up to 4096 for CALR, 256 for 
JR and 128 for D(B)JNZ. For CALR and JR the displacements are 
signed numbers, allowing access within a “shadow” centered on the 


15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 



( mode opcode 

0: Immediate or indirect register 
4: Direct addressed or indexed 
8; Register 

C: Special “high-density" instructions: 

CALR, JR, D(B)JNZ, LDB R,^ 

4.13: First Approximation to Z8000 Instruction Format 
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1 1 1 

c 

_ 1 _ 1 _ 1 _ 

-1-1- \ - 

R 

_ 1 _ 1_1 _ 

—1—1— 1 — 1 — 1 — 1 —r— 

0X 

_1_1_1_1_1_1_1_ 

LDB 

Immediate load of a byte register 

I I I 

D 

_ 1 _ 1 _ 1 _ 

I 1 1 1 1-1 1 1-1-1-1— 

displacement 

_1_1_i_1_1_1_1_1_1_1_1_ 

CALRX 

Coll using PC-relative addressing 

1 1 1 

E 

_ 1 _ 1 _ 1 _ 

I * 1 

cc 

_ 1 _ 1_1_ 

1 1 1 1 1 1—1— 

displacement 

_ 1_1_1_1_1_1 1 

JRcc,X 

Conditional jump using PC-relative addressing 

T 1 1 

F 

_ 1 _ 1 _ « 

1 I 1 

R 

- 1 _ 1 _ 1 _ 

1 1 1-1-1-1- 

W displacement 

-1-1_1_1_1_l_ 


D(B)JNZ R,X 

Looping instruction using PC-relative addressing 


4.14: The Four Special Instructions Designed for High Code 
Density 

instruction. For D(B)JNZ it is an unsigned number designating a 
backwards transfer of up to 128 words. 

Figure 4.14 also illustrates two other conventions that will be used 
in the 45 instruction descriptions later in this chapter: W and cc. The 
symbol W has the value 1 or 0, depending on whether the word or 
byte version of a given instruction is intended. In this example, DJNZ 
would have that bit set to 1, while DBJNZ would have it set to 0. The 
symbol cc, in the instruction format, denotes one of the 16 values of 
the 4-bit condition code field. In the sample assembly language state¬ 
ment below the format picture, it denotes one of the corresponding 
assembly mnemonics (see Figure 4.12). 

If the first two bits of the instruction are not both set to one, then 
that field is called the mode field, and the next 6 bits of the first byte 
are called the opcode field. (See Figure 4.13.) In general, the next byte 
is divided into two digits, each usually specifying the location of one 
of the arguments. Figure 4.15 shows an instruction falling into this 
typical pattern; it also illustrates several conventions. 
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—I— 

—1-1-1-1—I- 

-1-1-1- 

i • 1 

mode 

2C + W 

src 

dst R 

_l_ 

» i i_1_1- 

_1_1-1— 

« *_1— 


EX(B)R,src 


W = 0 for EXB, so op code is 2C 
W = 1 for EX, so op code is 2D 

Mode controls the src field; the dst field is always a register. 

4.15: A Typical Two-Operand Instruction 


First notice the assembly language statement 

EX(B) R.src 

below the format picture. It means that this picture represents the EX 
and EXB instructions, depending on the value of W in the picture (2D 
is the opcode for EX, 2C for EXB). The EX(B) instruction has two 
arguments: R and src. This notation means that the destination argu¬ 
ment (dst) of EX(B) must be a register (word or byte, depending on 
whether EX or EXB is specified). The source argument (src) can be 
addressed by any one of several addressing modes; the particular one 
to be used is specified in the mode field. In general, when an instruc¬ 
tion requires two arguments, the first specified in the assembly lan¬ 
guage statement is called the dst, usually indicating where the result is 
going. The second is called src, usually indicating an argument whose 
value will be undisturbed. In the format picture, we precede R by the 
word “dst.” In the case of EX(B) R,src this is a redundancy, but for, 
say, ADC(B) R,R the format picture must show which R is which. For 
consistency, we use the words “src” or “dst” in the format picture 
even when there is only one possible interpretation. 

No Z8000 instruction has more than one mode field. The address¬ 
ing modes for all but one of the arguments are implied by the instruc¬ 
tion (e.g., the dst of an EX(B) must be a register). In some instruc¬ 
tions all of the addressing modes are implied, so the mode field is not 
needed. In that case the mode field can be used to distinguish differ¬ 
ent instructions with the same opcode field (e.g., LDCTLB and 
RRDB). More frequently, not all of the three possible mode values 
will be usable by some instruction. The combination of that opcode 
and the unused mode setting wilt encode some other instruction (e.g.. 
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the opcodes for RET and JP are the same; RET uses the mode value 
corresponding to jumping to a register). 

Another variation is with one-argument instructions. There the 
mode field may be used to determine the addressing mode for the one 
argument, but the unused 4-bit argument field can be used to distin¬ 
guish different instructions with the same opcode (e.g., CLR(B), 
NEG(B), COM(B), TEST(B) all have the same opcode field). 

Four-bit fields are used for specifying arguments because every ad¬ 
dressing mode is specified in terms of a register. Any address or im¬ 
mediate argument implied by the addressing mode is appended to the 
basic instruction. This use of four-bit fields makes expression of in¬ 
structions in hexadecimal very convenient. For example (referring to 
Figure 4.15), the code for EX R3,R2 is AD23, since the mode field 
value for a register source is 8. This illustrates our convention for ex¬ 
pressing the three possible values of the mode field. Since they are the 
high order half of a hex digit, we call them 0, 4 and 8. That way they 
can be added to the high order digit of the opcode field (e.g., mode 8 
plus opcode 2D equals AD). (See Figure 4.13.) 

In the next chapter we shall discuss the Z8000 addressing modes in 
detail. At this point we only need to know how they are encoded in 
the mode fields of instruction. There are five main address modes 
available for most instructions: register (R), indirect register (@), im¬ 
mediate (#), indexed (X) and direct address (DA). The three values of 
the mode field (0,4,8) are not sufficient to encode five modes, so 
something must be borrowed from the four-bit register field. Fortu¬ 
nately, two of the modes do not require register specifications; thus, 
only 2 of the 48 mode/register combinations used by the other three 
modes need to be sacrificed. The choice made was to restrict use of RO 
with the indirect register and indexed modes. Figure 4.16 gives the en¬ 
coding. As noted above, the mode field controls only one address 


Mode 

Field 

Src 

Register 

Address Mode 

Dst 

Register 

Address Mode 

0 

1-15 

Indirect Register ((^) 

0-15* 

Indirect Register (@} 

0 

0 

Immediate (^) 



4 

1-15 

Indexed(X) 

1-15 

Indexed(X) 

4 

0 

Direct Address (DA) 

0 

Direct Address (DA) 

8 

0-15 

Register (R) 

0-15 

Register (R) 


*See CAUTION note on page 99. 


4.16: Encoding of Address Mode Using Mode and Register 
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mode in the instruction. The others are fixed (or controlled by other 
bits). Figure 4.16 shows that the encodings are slightly different de¬ 
pending upon whether the field controlled by mode is a src or a dst. 
The difference is that the immediate mode is not needed for dst fields, 
so RO can be used as an address register in that case. This distinction 
depends on the actual use of the argument. 

CAUTION: Since the first printing of this book, the manufacturer 
has announced that no use of RO in the @ mode will be 
supported. To be safe you should avoid using it. 


The Instruction Descriptions 

The 45 instruction descriptions at the end of this chapter provide 
detailed information on the operation, timing and formats of all of 
the Z8000 instructions. There could have been more or fewer than 45 
groups; the objective was to group similar instructions together but to 
avoid the contortions necessary to make one explanation fit two 
superficially similar instructions. This is the kind of trade-off in¬ 
volved in allocating program functions into modules or in deciding 
between writing two similar blocks of code or abstracting the similar¬ 
ities into a subroutine. Often it boils down to a matter of taste. It will 
be helpful to turn to these descriptions and page through them as you 
read the following explanation of their formats. 

In the upper left corner of each description is a number from 1 to 
45 used to identify it in the indices to be described later. Also in the 
upper left is a model assembly language statement using the conven¬ 
tion of parenthesized options discussed earlier. Below that, if neces¬ 
sary, is an expansion of the options into a list of the assembly lan¬ 
guage mnemonics covered by this description. The options (B) or (^) 
are not expanded. Some descriptions cover only one mnemonic (e.g., 
description 15), while others, primarily block instructions, cover many 
(e.g., description 20 covers 16 assembly mnemonics, even without 
expanding the (B) option). The Alphabetic Index to Instruction Des¬ 
criptions lists 105 separate assembler mnemonics; for each mnemonic 
the number of the relevant instruction description is given. 

Below the assembly language statement and mnemonic list is the 
name (or names) of the instruction being described. Below that is an 
explanation of what it does. In the explanations a distinction is made 
between instruction arguments (e.g., RO) and their value or contents 
(e.g., -2758). 
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In the upper right hand corner of each instruction description is a 
set of six boxes labeled C, Z, S, V or P, D, H. A dot in the box means 
that this instruction affects that FLAGS bit. If there is no dot in the 
box, the FLAGS bit is unaffected. If the designated FLAGS bits are 
used in their principal (arithmetic) sense (see Figure 4.17), then there 
will probably be no further mention of them in the description. If 
there is some unusual meaning attached to them it will be spelled out 
in the explanation. 

Below the explanation is a format picture. This is a rectangle repre¬ 
senting the 16 bits of the basic instruction (or sometimes two rectan¬ 
gles representing 32 bits). The rectangle is divided by vertical bars into 
fields (see Figure 4.15). With the exception of the mode field, these di¬ 
visions almost always occur on hex digit boundaries, although some 
fields are further broken down. If the particular instruction always 
has some fixed value in any of these fields, its hex representation is 
printed in the field. Otherwise, some designation, such as op, src R, 
D/I, dst, etc., appears. In the case of src or dst without a mode desig¬ 
nation like @ or R, the corresponding addressing mode will be con¬ 
trolled by the mode field. A note below the picture will indicate which 
of the modes 0, 4, 8 are available, and if these are not to be inter¬ 
preted exactly as specified in Figure 4.16, an explicit note to that ef¬ 
fect will appear. 

If more than one opcode is covered by the instruction description, 
then op will appear in the opcode field, and the various allowable val¬ 
ues and their meanings will be listed below the format picture. In op- 


C: Carry for addition, '"borrow" for subtraction, result outside the src range for 
multiplication and division. Register extension bit for shifts and rotations. 

Z: Result of zero for data operations and testing; condition match for block 
testing. 

S: Result negative (high order bit set) for data operations and testing; Ml set for 
multi-micro sync. 

V: Arithmetic overflow (variously defined) for arithmetic, shift/rotate and 
counter/point varying operations; zero count for block instructions. 

P: Parity even for byte versions of logical and testing operations. 

D: Byte subtraction performed, cleared for byte addition. 

H: Carry from low order digit during byte addition or subtraction. 


4.17: Conditions Reported by FLAGS bits 
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code specification the symbol W is used (see Figure 4.15) to distin¬ 
guish word and byte versions. Another way to express this would be: 
bit 8 of the instruction is set for word operations, clear for the byte 
versions; but since not all instructions (even within the same instruc¬ 
tion description) use bit 8 in this way, it seemed clearer to write “op 
-f W”, where W == 1 or W = 0, instead of drawing a field division 
in the format picture. 

In some cases (e.g., LDK R,#n) an immediate argument is encoded 
into the instruction, not added on as an extra word as it would be if it 
were the “mode 0, R0“ encoding of a src field. In this case #n appears 
in the appropriate field of the format picture. 

In some cases (e.g., LDCTL dst,src) a field is sometimes a src, and 
sometimes a dst. In this case it is given a mnemonic name but treated 
exactly as a src or dst. Sometimes (e.g., block translate and test) the 
designations src and dst are meaningless and are eliminated altogether. 
Then the uses of the various fields are given explicitly. 

To the right of the format picture the instruction timing is given. 
For some instructions this is a fixed number of cycles. More often it is 
a table giving times in cycles for various address modes or instruction 
variations. Sometimes (e.g., block instructions) the timing is a for¬ 
mula, depending on some parameter such as the number of execu¬ 
tions. The timings given are for the non-segmented case. Timings for 
the segmented case can be computed easily from these using Figure 
4.18. The only difference occurs when an address is appended to the 
instruction. The difference is the same for word, byte or long-word 
versions. The only address modes affected are direct address and in¬ 
dexed. The amount of difference depends upon whether short or long 
segmented addresses are used; these will be discussed in Chapter V. 
The way to use Figure 4.18 is to add the indicated number of cycles to 
the non-segmented timing given in the instruction description. If the 


DA X 

Short 
Address 

Long 
Address 


-f 1 

4-0 

+ 3 

-h3 


4.18: Additional Time (Cycles) for Segmented Addressing 
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given timing is a formula (e.g., 11 + 14n), the number is added only 
to the constant part, not to the coefficient of n. 

Below the format picture appear special notes or warnings, then in 
most cases there is an example. First, initial conditions are given if the 
example is going to follow the effect of the operations, or, if the ex¬ 
ample is meant to illustrate a technique, this is explained. Then come 
assembly language statements. If the example is following the effect 
of the operations, then the comments indicate changing values of 
registers, memory and FLAGS bits. Otherwise the comments explain 
the purpose of the particular instructions in implementing the tech¬ 
nique being illustrated. 

The Indices 

There are two indices provided to the instruction descriptions: one 
alphabetic by assembler mnemonic, one numeric by opcode field (bits 
13-8). For the alphabetic index, the number of the corresponding in¬ 
struction description is given. For the numeric index, one opcode may 
correspond to several descriptions. In this case the number of each 
description is given, followed by the assembler mnemonics corres¬ 
ponding to the given opcode that are described in the specified 
description. In this index, pairs of opcodes are grouped together (e.g., 
00/01,02/03) when they represent byte and word versions of the same 
instruction. 


How to Use the Instruction Descriptions 

In this section we shall go through some detailed examples illus¬ 
trating the use of the instruction descriptions. 

Let us begin by looking at Instruction Description 2; notice that in 
the upper left hand corner is 

R,src 


and below that is 


ADD(B), SUB(B) 

The first of these lines tells us in compact form exactly what instruc¬ 
tions are dealt with in this description and what form they take in 
assembly language. In other words, all of the instructions described 
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here take two arguments: a register (for the destination) and a source 
(controlled by the mode field), for example, 


ADDB RH0,#5 
SUBL RR2,RR4 
ADD R3,@R1 
SUB R7,TABLE(R3) 

The second of the two lines 

ADD(B), SUB(B) 

expands the instruction mnemonic portion of the first line. That may 
not seem necessary here, but turn for a moment to Description 20 to 
see a case in which the first line expands into 16 instruction mnemon¬ 
ics. We could have expanded further into 

ADD, ADDB, ADDL, SUB, SUBB, SUBL 

but that seemed to confuse rather than to clarify. For Description 20, 
that would have resulted in 32 assembler mnemonics. 

Under these two lines is a third line, the instruction name 

Add/Subtract 

The word mnemonic comes from the Greek mnemnos, meaning 
memory. A good mnemonic instruction name helps you remember 
what the instruction does. ADD and SUB are good mnemonics, so the 
instruction name 


Add/Subtract 

seems superfluous. But look at Description 44, where the mnemonics 
are 

TRDB, TRDRB, TRIB, TRIRB, TRTDB, TRTDRB, TRTIB, TRTIRB 
Here it is helpful to be told that this is the Block Translate instruction. 
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Under the name, there is a verbal description of what the Add/ 
Subtract instruction does. Look back at Figure 4.1. For ADD, the 
source value and the destination value are moved into the arithmetic 
and logical unit, where they are added together and the result stored 
back into the destination register. These are the mechanics of the in¬ 
struction. The effect is that the source value is added to the value in 
the destination register, and the result is left in the destination regis¬ 
ter. The verbal description tells us the effect of the instruction, not 
necessarily the mechanics. The programmer does not usually need to 
be concerned with the mechanics of instruction execution. 

The next thing below the verbal description is the instruction for¬ 
mat picture. Notice that there are four fields in the Add/Subtract in¬ 
struction: 


mode, op, src, dst R 

The first of these is the mode field. It controls the src field. That 
means that the mode and src fields are taken together and interpreted 
according to the left half of the table in Figure 4.16. We shall come 
back to this but remember that you don’t need to know any of this if 
you are just writing down assembly language instructions. In other 
words, when you write 


ADD R0,@R4 

the assembler program takes care of setting the mode field to zero and 
the src field to 4. It is only when you are trying to construct the hex 
version of the instruction yourself, without using an assembler, or 
when you are confronted with a hex code and need to figure out what 
instruction it represents, that you have to know how the mode and src 
fields are interpreted. 

Of course, what we just said applies equally to the op and dst R 
fields. When you write 


ADD R0,@R4 


the assembler sets the op field to 1 and the dst R field to 0; you don’t 
need to worry about it. 

Notice that there are two notations below the format picture: one 
concerning the op field and one concerning the src and mode fields. 
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The notation 


src modes: 0, 4, 8 

is a shorthand for saying that the src and mode fields are to be inter¬ 
preted exactly as in the table in Figure 4.16. In particular, this means 
that you may not write 


ADD R5,@R0 
or 

ADD R5,TABLE(R0) 

since the first would be interpreted as signaling an immediate argu¬ 
ment and the second would mean a direct address. Of course, an ade¬ 
quate Z8000 assembler will reject these statements. You need only be 
concerned with the details of Figure 4.16 when you are doing the as¬ 
sembler’s job yourself. 

The notation concerning the op field tells us that it can take six dif¬ 
ferent hex values: 0 = ADDB; 1 = ADD; 16 = ADDL; 2 = 
SUBB; 3 = SUB; 12 = SUBL. Recall that the symbol W takes the 
value 0 for a byte instruction, and 1 for a word instruction. This is 
simply another form of shorthand. 

Looking to the right of the format picture we find a table of in¬ 
struction times. Along the top of the table are the five possible source 
modes: R, @, DA and X. These are abbreviations for the register, 
immediate, indirect register, direct and indexed addressing modes, 
which will be discussed in Chapter V. Generally, all of these modes 
take different numbers of cycles because of the different ways they 
obtain their arguments (actually, ^ and @ are always equal). Unfor¬ 
tunately, there is no formula that lets us compute all of them from 
some basic instruction time, since instructions vary in the extent to 
which computing and operand fetching overlap. Along the left side of 
the table appear the labels “ADD(B), SUB(B)” and “ADDL, 
SUBL.” That means that the first row of the table gives timings for 
ADD, ADDB, SUB, SUBB; the second row is for ADDL and SUBL. 
The long-word versions take longer because there are two operations 
to be done, one after the other, and there are twice as many memory 
fetches (in the non-register modes). 

These times are all in cycles. The actual time required depends upon 
the clock rate. At 4 MFIz, 4 cycles 1 microsecond; thus, 

ADD R0,R1 
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takes 1 microsecond to execute, while 


ADDL RR0,TABLE(R2) 
takes 4 microseconds (16 cycles). 

Another point is that these times are all for non-segmented opera¬ 
tion. The segmented operation times can be computed from them us¬ 
ing the table in Figure 4.18. First of all, only the DA and X modes are 
affected. As we shall see in Chapter V, these are the address modes in 
which an address appears as part of the instruction. These addresses 
are one word long for non-segmented operation and either one or two 
words long for segmented operation. It would seem, therefore, that 
for segmented operation the instructions should take 3 cycles more 
(the time for a memory fetch) when two-word addresses are used and 
exactly the same number of cycles as for non-segmented operation 
when the one-word addresses are used. This is almost true. The only 
exception is that direct addressing takes one cycle longer with a one- 
word segmented address than it does with a one-word non-segmented 
address. For example, if we want to know how long an ADDL takes 
using a two-word segmented address for the DA mode, we look in the 
table of Figure 4.18 to find -f 3, and we add that to the 15 cycles shown 
in Description 2 to obtain 18 cycles. Similarly, for an ADD or ADDB 
with the same segmented address, the time would be 12 cycles. If a 
one-word segmented address were used instead in these two examples, 
the times would be 16 cycles and 10 cycles. 

Now the last thing to note in Description 2, before we look at the 
example at the bottom, is the set of boxes in the upper right hand cor¬ 
ner labeled C, Z, S, V, D, H. A similar set appears in the same loca¬ 
tion for each instruction description, but sometimes V is replaced by 
P or by V/P (or P/V). These are the six FLAGS bits. Notice that 
there is a dot in each of the boxes, and that no other mention of 
FLAGS bits appears in the description. This means that all of the bits 
are affected by these instructions and that the way they are affected is 
as described in Figure 4.17. Looking back at Figure 4.17 we see that 
this means: 

C: Set to indicate carry for addition or “borrow” for subtrac¬ 
tion. Clear if none. 

Z: Set if result is zero. Clear if non-zero. 

S: Set if result is negative. Clear if positive. 

V: Set if overflow (see Chapter I). Clear if none. 
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D: Set by SUBB. Cleared by ADDB. Left unaffected by ADD, 
SUB, ADDL, SUBL. 

H: Set if carry from low order 4-bit digit to high order 4-bit digit 
during ADDB, SUBB. Clear if no such carry during ADDB, 
SUBB. Left unaffected by ADD, SUB, ADDL, SUBL. 

These boxes are a shorthand way of representing a large amount of 
information. 

Finally, at the bottom of Description 2 is an example of how the 
Add/Subtract instruction is used. It begins by stating some initial 
conditions: RO contains the value 12, R1 contains 15, the byte regi¬ 
sters RH2 and RL2 contain 126 and 3. Then there are two assembly 
language statements. The comments give the values of the registers in¬ 
volved and the affected FLAGS bits, after the instruction has been ex¬ 
ecuted. 

For example, with the given conditions, 

ADDB RH2,RL2 

causes the 3 in RL2 to be added to the 126 in RH2; the result is 129, 
which is placed in RH2. But 129 is actually - 127 in 8-bit two’s com¬ 
plement, so overflow has occurred. The FLAGS bits reflect the result: 
C = 0, since no carry occurred (the sum would have had to exceed 
255); Z = 0, since the sum is not zero; S = 1, since - 127 is negative; 
V = 1, since the sum of two positive numbers was negative; D = 0, 
since the instruction was ADDB; H = 1, since a carry occurred in 
adding the low order digits (14-1-3 = 17 = 16-1-1). The 16 is the 
carry to the high order digit. 

The next instruction: 


SUB RO, R1 


is not a byte instruction; D and H are unaffected. The result of sub¬ 
tracting 15 from 12 is -3. Therefore, C = 1 (a “borrow” has oc¬ 
curred); Z = 0, since the result was not zero, S = 1, since -3 is 
negative; and V = 0, since there was no overflow. 

In the example for Description 2, the two instructions are indepen¬ 
dent of each other. They are there to illustrate different things. In In¬ 
struction Description 1, on the other hand, there are two sequences of 
instructions. In each of these sequences, the register values and 
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FLAGS bits resulting from each instruction become the initial values 
for the next instruction. This dependence of each instruction on the 
preceding one is emphasized by the connecting of the boxes contain¬ 
ing the FLAGS values. 

Now that we have gone through one Instruction Description com¬ 
pletely, we shall try to use the Instruction Descriptions to help us 
figure out the hex instruction codes for an actual program—the 
LENGTH subroutine shown in Figure 3.7. In doing this, we shall be 
using the Alphabetic Index to Instruction Descriptions to help us find 
the instructions we are assembling. To make the example concrete, we 
shall assume that the program is to be assembled starting at memory 
location 1000,6. 

The first line is 


LENGTH: PUSH @SR,R1 

The LENGTH: portion causes the value 1000,6 to be assigned to the 
symbol LENGTH, but since LENGTH is never referred to inside this 
subroutine, we will not need to use that fact. To assemble the instruc¬ 
tion, we look in our index to find that PUSH is described in Instruc¬ 
tion Description 36. Turning to that Description, we find two format 
pictures: one for immediate sources (e.g., PUSH @SR,^5), the other 
for all other source modes. The top picture is the one we need, since 
we do not have an immediate source; ours will be using the register 
(R) mode. 

Let us fill in the four fields from left to right: mode = 8 for 

register mode (see Figure 4.16); op = 13 for PUSH (see the notation 
below the picture); for dst @R we fill in the register number for SR 
(this will be explained in Chapter V). Since our example is written for 
non-segmented operation, the stack register is R15. The hex for 15 is 
F, so we set the dst @R field to F. Finally, we set src = 1 to desig¬ 
nate Rl. Thus, 

PUSH @SR,R1 is 93F1 

Notice how the mode of 8 was added to the first digit of the op of 13 
to get 93 as the hex value of the first half of the word. 

Similarly, the next instruction 

PUSH@SR,R2 is 93F2 
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The only difference is that the src field is 2 (for R2) instead of 1 (for 
Rl). 

For the next instruction 

CLR RO 

the index tells us to look at Description 6. Filling in the fields as 
before, we have mode = 8 for register mode; op = OD (OC + 1, 
since W = 1 for CLR, 0 for CLRB); dst = 0 for RO. The fourth 
field is already filled in for us; the final digit of 8 is what distinguishes 
CLR from NEC, COM and others. Putting them together, we get 

CLRRO is 8D08. 

Similarly, the next instruction 

CLRBRL2 is 8CA8. 

Notice the difference between the C and D in the second digits of the 
last two instructions. This is because W = 0 for CLRB, so the op is 
OC; and adding the 8 for register mode gives 8C. The other thing to 
note is the A for RL2. All of the other registers that we have seen up 
to now were encoded by their numbers: RO was encoded by 0, Rl by 
1, R2 by 2. This is also true of long-word registers—RR2 is encoded 
by 2, etc. But for byte registers, we can’t encode both RL2 and RH2 
by 2. We need a way to tell them apart. So for the RL byte registers, 8 
is added to the number: RLO is encoded by 8, RLl by 9, RL2 by A (as 
here), etc. This is discussed in Chapter V. 

Next we come to 


CPIRB RL2,@R1,R0,EQ 

which the index shows to be covered under Description 10. This in¬ 
struction has no mode field, since the only variation allowed is be¬ 
tween dst = @ and dst = R, as shown in the notation for the S 
(string) option under the format picture. The op field takes the value 
BA, since W = 0 for the byte version. Our src @R field gets the 
value 1 for Rl. The last digit of the first word has D/I = 0 for incre¬ 
ment, R = 1 for repeat and S = 0 for dst = R. This gives OIOO 2 , or 
4,6; thus, the first word is BAM. In the second word, the cnt R field 
gets 0 for RO, the dst field gets A for RL2 and the cc field gets 6 for EQ 
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(see Figure 4.12). This gives 00A6 for the second word; that is 

(BAH 

CPIRB RL2,@R1,R0,EQ is j 

Now you should be able to work out the remaining five instruc¬ 
tions: 


NEG RO 

is 8D02 

DEC RO 

is ABOO 

POP R2,@SR 

is 97F2 

POP R1,@SR 

is 97F1 

RET 

is 9E08 


Figure 4.19 shows the completely assembled program. The leftmost 
column contains the hex addresses and the next column has the ma¬ 
chine code corresponding to the source instruction, which appears in 
the rightmost column. Notice also that we never made use of the hex 
addresses in assembling the program. The same 11 words of code 
could be placed at any address, and they would do exactly the same 
thing. This is known as position-independent code. 

In fact, in the subroutine version of the encryption program (Figure 
3.9), the MOD23 subroutine (Figure 3.8) and the LENGTH subroutine 
that we just assembled, there are only two instructions that depend 
upon the actual addresses at which the programs are assembled. These 


Address 

Contents 


1000 

93F1 

LENGTH: PUSH @SR,R1 

1002 

93F2 

PUSH @SR,R2 

1004 

8D08 

CLR RO 

1006 

8CA8 

CURB RL2 

1008 

BAH 

CPIRB RL2,@R1,R0,EQ 

lOOA 

00A6 


lOOC 

8D02 

NEG RO 

lOOE 

ABOO 

DEC RO 

1010 

97F2 

POP R2,@SR 

1012 

97F1 

POP R1,@SR 

1014 

9E08 

RET 


4.19: Assembled Version of LENGTH 
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instructions, CALL LENGTH and CALL MOD23, are both in Figure 
3.9. They use the direct address mode. 

From Instruction Description 5 we see how to assemble these in¬ 
structions. If the LENGTH subroutine is at 1000 (as in Figure 4.19), 
then (using mode = 4, dst = 0—see Figure 4.16), 

CALL LENGTH is \ 

( 1000 

The actual address of LENGTH is the second word of the instruction. 

As a final illustration of how to use the Instruction Descriptions, 
we shall disassemble a program. Figure 4.20 shows a section of hex 
code that we wish to translate into assembler mnemonics. 

We start with ABF9 at location 3000. A = 8 -h 2, so we have 
mode = 8, op = 2B. We look in the numeric index and find a row 

2A/2B 12 DEC(B) 

This tells us that 2B is a DEC instruction and that Description 12 will 
give us its format. Turning to 12, we find that 

ABF9 is DEC R15,//10 

since mode = 8 means register mode (see Figure 4.16), F encodes 
R15 and 9 = n- 1. 

The next instruction at 3002 is 1CF9. Our numeric index tells us 
that 1C is an LDM and refers us to Description 28. There we find that 
the final digit of 9 determines that it is an LDM from registers to 
memory. The F encodes R15, and since mode = 0, it is @R15. We 
also see that we must look at the next word, the 0004 at 3004, to find 
that the register is RO and the number of registers is 5. We have 

1CF9) 

0004 ! '' @SR,R0,^5 

Since the 0004 was part of the LDM instruction, the next word we 
must look at is the A104 at 3006. A = 8 + 2, so we have mode = 
8, op = 21. Looking in the numeric index under 21 leads us to 
Description 23 for the LD instruction. The 04 means src = RO, dst 
= R4; thus. 


A104 is LD R4,R0 


Z8000 INSTRUCTION SET 111 



The next two words we recognize as a CALL to the subroutine at 
location 1000 (or if we don’t recognize it, our index tells us that op 
= IF is a CALL). Since we do not know what subroutine is at 1000 
for this example, we can call it SUBl. Thus, 

CALL SUBl 

We are now up to 3(X)C, where we find A103; you should be able to 
figure out for yourself that 

A103 is LDR3,R0 
8D28 is CLRR2 
2048 is LDBRL0,@R4 
8C84 is TESTS RLO 

This brings us to the E609 at 3014. E = C + 2, but there is no mode 
= C. This is one of the four special instructions (see Figure 4.14). E 
= JR; 6 encodes a condition code (Figure 4.12); and 09 is a dispace- 
ment. JR is described in Description 22, where we find out how to in¬ 
terpret the displacement. We take 09, multiply it by 2 to get 12 
(remember, this is hex), and add it to the address following this in¬ 
struction (i.e., 3016), so the destination of the JR is 3016 -I- 12 = 
3028. All we can do is make up a label for 3028; we shall call it XX. 
Finally, looking at Figure 4.12, we see that the condition code 6 is Z 
or EQ. Since the preceding instruction was TESTS RLO, we should 
call it Z (although it makes no difference). Then 

E609 is JR Z,XX 

The next instruction, 7010, makes us work a little harder. Looking 
in our index under op = 30, we find Description 11, DAS, Descrip¬ 
tion 17, EXTS(L)and Description 23,LD(S).DAS seems very unlikely, 
butifwelookthereanyway, we find only SO, i.e., mode = 8, op = 30. 
Since we have mode = 4 we can go on. EXTS also seems unlikely, 
and when we look that up we find mode = 8, op = 31. Thus, LD(B) 
is what it must be. In fact, it is the last format shown in Description 
23: a Sase Indexed Load. Looking at the format you should be able 
to see that 

is LDS RH0,R1(R2) 
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Address 

3000 
3002 
3004 
3006 
3008 
300A 
300C 
300E 
3010 
3012 
3014 
3016 
3018 
301A 
301C 
301E 
3020 
3022 
3024 
3026 
3028 
302A 
302C 
302E 


Contents 

ABF9 

1CF9 

0004 

A104 

5F00 

1000 

A103 

8D28 

2048 

8C84 

E609 

7010 

0200 

8808 

2E48 

A940 

A920 

5F00 

2000 

E8F4 

ICFl 

0004 

A9F9 

9E08 


4.20: Mystery Program 


From here on, you ought to be able to finish the example for 
yourself. What relation does this program have to Figure 3.9? 

Some Design Considerations 

The author is well aware that there are many ways to present the 
kinds of information found in the Instruction Descriptions. The au¬ 
thor is also aware that his presentation does not conform to the style 
most widely used in engineering manuals. Here are some questions 
the author had to consider. His answers are here in this book; he 


Z8000 INSTRUCTION SET 113 






would welcome hearing the opinions of others on this subject, espec¬ 
ially those who have had a chance to use this book as an aid to their 
work with the Z8000. 

• Should the Instruction Descriptions be a tool (like an oscillo¬ 
scope) that is efficient to use but can’t be used at all without 
some preparation? 

• Should central things like the mode encodings (Figure 4.16), the 
condition codes (Figure 4.12) and the FLAGS interpretations 
(Figure 4.17) appear in just one place (and possibly be memor¬ 
ized by the programmer), or should they be replicated in each 
place where they are used? 

• Should there be one instruction description for each of the 105 
separately identifiable instruction mnemonics (187 if B’s and L’s 
are considered separately), of should the similarities among 
groups of instructions be emphasized by treating them together? 

• Should hexadecimal be used, even though it leads to awkward 
situations like modes of 0, 4 and 8, or should binary representa¬ 
tion be used? 

These are some questions that the author considered explicitly. 
There are many other implicit decisions the author may have made 
simply by failing to see that there was an alternative. Again, any 
reader comments will be welcome. 
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INDEX TO INSTRUCTION DESCRIPTIONS 
(Alphabetical) 


ADC(B) 

1 

INC(B) 

12 

OTDR(B) 

20 

ADD(B) 

2 

IND(B) 

20 

OTIR(B) 

20 

AND(B) 

3 

INDR(B) 

20 

OUT(B) 

19 

BIT(B) 

4 

INI(B) 

20 

OUTD(B) 

20 

CALL 

5 

INIR(B) 

20 

OUTI(B) 

20 

CALR 

5 

IRET 

21 

POP(L) 

35 

CLR(B) 

6 

JP 

22 

PUSH(L) 

36 

COM(B) 

7 

JR 

22 

RES(B) 

4 

COMFLG 

8 

LD(B) 

23 

RESFLG 

8 

CP(®) 

9 

LDA 

24 

RET 

37 

CPD(B) 

10 

LDAR 

24 

RL(B) 

38 

CPDR(B) 

10 

LDCTL(B) 

25 

RLC(B) 

38 

CPI(B) 

10 

LDD(B) 

26 

RLDB 

39 

CPIR(B) 

10 

LDDR(B) 

26 

RR(B) 

38 

CPSD(B) 

10 

LDI(B) 

26 

RRC(B) 

38 

CPSDR(B) 

10 

LDIR(B) 

26 

RRDB 

39 

CPSI(B) 

10 

LDK 

27 

SBC(B) 

1 

CPSIR(B) 

10 

LDM 

28 

SC 

40 

DAB 

11 

LDPS 

29 

SDA(l) 

41 

DEC(B) 

12 

LDR(«) 

30 

SDL(f) 

41 

DI 

13 

MBIT 

31 

SET(B) 

4 

DIV 

14 

MREQ 

32 

SETFLG 

8 

D(B)JNZ 

15 

MRES 

31 

SIN(B) 

19 

El 

13 

MSET 

31 

SIND(B) 

20 

EX(B) 

16 

MULT(L) 

33 

SINDR(B) 

20 

EXTS(®) 

17 

NEG(B) 

7 

SINI(B) 

20 

HALT 

18 

NOP 

34 

SINIR(B) 

20 

IN(B) 

19 

OR(B) 

3 

SLA(B) 

41 
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SLL(B) 

41 

SRL(B) 

41 

TRIRB 

44 

SOTDR(B) 

20 

SUB(®) 

2 

TRTDB 

44 

SOTIR(B) 

20 

TCC(B) 

42 

TRTDRB 

44 

SOUT(B) 

19 

TEST(^) 

43 

TRTIB 

44 

SOUTD(B) 

20 

TRDB 

44 

TRTIRB 

44 

SOUTI(B) 

20 

TRDRB 

44 

TSET(B) 

45 

SRA(B) 

41 

TRIB 

44 

XOR(B) 

3 
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INDEX TO INSTRUCTION DESCRIPTIONS 
(By numeric value of opcode) 


OP 


Description(s) 

OP 

Description(s) 

00/01 

2 

ADD(B) 

18/19 

33 

MULT(L) 

02/03 

2 

SUB(B) 

lA/lB 

14 

DIV(L) 

04/05 

3 

OR(B) 

1C 

28 

LDM 

06/07 

3 

AND(B) 


43 

TESTL 

08/09 

3 

XOR(B) 

ID 

23 

LDL 

OA/OB 

9 

CP(B) 

IE 

22 

JP 

OC/OD 

6 

CLR(B) 


37 

RET 


7 

NEG(B),COM(B) 

IF 

5 

CALL 


8 

('P)FLG 

20/21 

23 

LD(B) 


9 

CP(B) 

22/23 

4 

RES(B) 


23 

LD(B) 

24/25 

4 

SET(B) 


25 

LDCTLB 

26/27 

4 

BIT(B) 


34 

NOP 

28/29 

12 

INC(B) 


36 

PUSH 

2A/2B 

12 

DEC(B) 


43 

TEST(B) 

2C/2D 

16 

EX(B) 


45 

TSET(B) 

2E/2F 

23 

LD(B) 

OE/OF 


Unimplemented 


42 

TCC(B) 

10 

9 

CPU 

30/31 

11 

DAB 

11 

36 

PUSHL 


17 

EXTS(®) 

12 

2 

SUBL 


23 

LD(B) 

13 

36 

PUSH 


30 

LDR(B) 

14 

23 

LDL 

32/33 

23 

LD(B) 

15 

35 

POPE 


30 

LDR(B) 

16 

2 

ADDL 


38 

R(^)(C)(B) 

17 

35 

POP 


41 

S(L)(i:)(^ 
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OP 


Description(s) 

OP 


Description(s) 

34/35 

1 

ADC(B) 


21 

IRET 


23 

LDL 


26 

LD(f)(R)(B) 


24 

LDA.LDAR 


31 



30 

LDRL 


32 

MREQ 

36/37 

1 

SBC(B) 

3C/3D 

13 

(e)I 


23 

LDL 


19 

IN(B) 


24 

LDA 


25 

LDCTL 

38 

44 

TR(T)(°)(R)B 


27 

LDK 

39 

29 

LDPS 


39 

RRDB 

3A/3B 

10 

CP(S)(?)(R)(B) 

3E/3F 

19 

OUT(B) 


18 

HALT 


39 

RLDB 


19 

(SXqIn^XB) 


40 

SC 


20 

(S)(ouT)(f)W(B) 





The Four Special Instructions 

First Digit 

Description 

C 

23 LD(B) 

D 

5 CALR 

E 

22 JR 

F 

15 D(B)JNZ 
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1. (gg)c(B) dst R,src R 


ADC(B), SBC(B) 


Add/Subtract with Carry 

The sum of the source value and the C bit is added to/subtracted 
from the destination value; the result replaces the destination value. 


op 


src R 


dst R 


Time (cycles): 5 


op: 


B4 + W = ADC(B) 
B6 + W = SBC(B) 


Example: RHO = O; RLO = = 2; RH4 = 0 ; RL4 = 1 ; RH5 = 3. 


ADDB RH1,RH5 
ADCB RL0,RL4 
ADCB RH0,RH4 


!RH1 = 5; RH5 = 3; 
!RL0 = 0;RL4 = 1; 
!RH0 = 1;RH4 = 0; 



C Z S V D H 


In this way the 24-bit number 259 stored in RH4,RL4,RH5 has been 
added to the 24-bit accumulator RH0,RL0,RH1. The initial value in 
the accumulator was 65,282; the final value is 65,541, and the final C 
value of 0 indicates that the sum produced no carry. 

With the same initial values 


SUBB RH1,RH5 !RH1 = -1; RH5 = 

SBCB RL0,RL4 !RL0 = -3; RL4 = 

SBCB RH0,RH4 !RH0 = 0; RH4 = 

C Z S V D H 



In this case, 65,282 - 259 = 65023, and the final C value of zero 
indicates that the difference required no borrow. 
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(subH®) 


src 

ADD(®), SUB(») 


Add/Subtract 

The source value is added to/subtracted from the destination value, 
and the result replaces the destination value. 

src 

R » @ DA X 

ADD(B),SUB(B) 

ADDL.SUBL 

src modes: 0,4,8 Time (cycles) 

/ 00 + W: ADD(B) 

J 16: ADDL 
\02 + W: SUB(B) 

* 12: SUBL 

Example: ro = 12 ; ri = is; rh 2 = 126 ; rl 2 = 3 . 





ADDB RH2,RL2 !RH2 


-127; RL2 



SUB R0,R1 
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'j /AND. 

3. ( OR )(B) R,src 
XOR 

AND(B), OR(B), XOR(B) 



And/Or/Exclusive Or 

The result of the indicated logical operation on the source and destina¬ 
tion values replaces the destination value. 



A fi Time (cycles) 

src modes: 0,4,8 


! 06 + W: AND(B) 

04+ W: OR(B) 

08 + W: XOR(B) 

Example: RHO = 7A..; RLO = 64i.; R1 = FOTO..-, R2 = lOFF,,. 

XORB RHO,RLO !RH0 = IE..; RLO = 64„; | o | o | ' | ! 

z s P 

AND R1,R2 !R1 = 1070..; R2 = lOFF..; ! 

OR R1,R2 !R1 = lOFF..; R2 = lOFF..; |o |o | '• 

z s 
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BIT 

4. (rES)(B) dst,src 
SET 


BIT(B), RES(B), SET(B) I 1*1 I I I 

C Z S V D 

(BIT(B) only) 


Bit Test/Reset/Set 

The bit in question is set to 1 for SET(B), cleared to zero for RES(B) 
or tested (and left unchanged) for BIT(B). For BIT(B), Z is set if the 
bit is zero, cleared if the bit is 1. SET(B) and RES(B) affect no status bits. 

The bit in question is that bit of the destination value whose number 
is in the low order three or four bits of the source value. Bits are num¬ 
bered from zero for the lowest order (rightmost) bit up to 7 or 15 for 
the highest order (leftmost) bit. 


—1— 

mode 

—1-1—1-1—1— 

op 

-1—1—1— 

dst 

1 1 1 

A'Bit no. 

—1-1—1— 


dst modes: 0, 4, 8 


IMMEDIATE SOURCE 


dst 



R 

@ 

DA 

X 

BIT(B) 

4 

8 

10 

11 

RES(B)/SET(B) 

4 

11 

13 

14 


Time (cycles) 


—1—1- 1 - 

0 

—1-1—1— 

P 

—1—1—1— 

0 

—1—1—1— 

src R 

“'■■'I' I" 1 

0 

_1_1_l__ 

1 1 1 

dst R 

_1_1_ 

1 1 1 

0 

_1_1_1_! 

0 

—1—i—1_ 


DYNAMIC SOURCE 


! 26 + W: BIT(B) 
22 + W: RES(B) 
24 + W: SET(B) 
(Both Formats) 


Time (cycles): 10 


Note: The src register for dynamic source is a word register, for either 
byte or word versions. For byte versions it is restricted to be RO to R7; 
for word versions RO to R15 can be used. 
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Example: RO = l; R2 = 8; R3 = O; R4 = FFFF... 


SET R0,R2 
SETB RL0,R4 
RES R0,R3 
BITB RHO,#! 
BITB RH0,R3 


!RO = 

101,a; 

R2 

!R0 = 

ISlia; 

R4 

!RO = 

180,a; 

R3 

!R0 = 

180,a; 

Z 

!R0 = 

180,a; 

R3 


= 8 

= FFFF ! 

= 0 ! 

1 ! 

= 0;Z = 0 ! 
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^CALR^ **** 


C Z S V D H 


Call Subroutine 

The PC is pushed via the stack register (R15 or RR14); then the desti¬ 
nation address (NB: not the destination value as with other instructions) 
replaces the PC contents. 


—1— 

—1-1-1—1—1— 

-1—1—1— 

—1—1—r“ 

@ 

DA 

X 

mode 

_1_ 

IF 

—1-1—1 1 1 

dst 

_1_1_1_ 

0 

_1_1_L_ 


10 


Lli 


dst modes: 0,4, (not 8) Time (cycles) 


CALL 


T—I-1--1-1-1-1-1-1-1-1-1-1-T 

D dst displacement from PC 

J-1-1--1-1-1-1-1-1-1_I_I_I_L 


CALR 


Time (cycles): 10 


For CALR, the destination address is computed as follows: the 
displacement is taken as a signed 12-bit value, multiplied by 2, then 
subtracted from (NB: not added to) the address of the location following 
the CALR. (Thus, CALR can be used for destination addresses in the 
range $ - 4092 to $ + 4098.) 

Note: (1) CALR will never change the segment part of the address. 
(2) CALL and CALR timing in the segmented modes are 5 
cycles more than the values calculated using Figure 4.18: 


short adr. 

Time (cycles): 15 


Time (cycles) 

CALR CALL 


(g DA X 


W\ 

18 

18 

15 

20 

21 
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Example: RR14 = (300,„100,«); pc = (200 ,6,10,t); address XYZ is at segment 1, 
offset 200,6; stack memorj' locations in segment 3: FA,6 = 0000; FCi6 = 0000; 
FE,6 = 0000; 100,6 = 1000,6. 

CALL XYZ IRR14 = (300,6,FC,6); PC = (100,6,200,6); 
stack memory locations in segment 3: 

FA,6 = 0000; FC,6 = 200,6; FE,6 = 10,6; 

100,6 = 1000 , 6 ! 

In this example, the address of the location following the CALL has 
been pushed onto the stack controlled by RR14, and the new PC value 
is the address XYZ. 
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6. CLR(B)dst 


C Z S V D H 

(Note: Z not set) 

Clear 

The destination value is replaced by zero. 


Time (cycles) 

Example! R1 = IOOOk; R2 = 1002i 6; data memory: 1000,6 = -1; 1002,6 = -1. 
CLR @R1 !R1 = 1000,6; memory location 1000,6 = 0! 

CLRB @R2 !R2 = 1002,6; memory location 1002,6 = FF,6! 

Special Note: Under consideration for the future versions of the Z8000 
is a CTRL instruction of the form 


—1— 

mode 

■ 

—1—1—1—1—1— 

oc + w 

—1—1_1_1_ 

—r— 1 —r— 

dst 

—1—1_1_ 

—1—1 

8 

—1_1_1_ 


dst modes: 0,4, 8 


dst 

R @ DA X 



8 

E 

12 


mode 

1 1 - 1 - 1 -r—- 

1C 

—J—1_l__l_ 1 _ 

-T"— 1 - 1 - 

dst 

_l_L_l_ 

— 1 1 1 - 

0 

__J 1 _ 1 _ 
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7. (CO^(B) ds. 

COM(B), NEG(B) 


• • • 


Z S P/V D H 


Complement/Negate 

The destination value is replaced by its complement/negative. Z, S 
and P are set according to the result for COM(B). For NEG(B), Z and 
S are as expected, C is set if the result is non-zero and V is set if the 
result is - 2'’ for NEG or - T for NEGB. 


R @ DA X 


—1— 

mode 

—r-T—1—1—1” 

oc + w 

—1—1—1— 

dst 

—m—r— 

op2 


7 

12 



_1— 

_l_1_1_1—i— 

_1 1 1— 1 

_1_1—1— 






dst modes: 0,4,8 Time (cycles) 


: COM(B) 
: NEG(B) 


/on 

Example: ro = -i; ri = -i; rh 2 = -m; rl 2 = f,. 


NEG RO 

COM Rl 


!R0 = 1; 
!R1 = 0; 


C Z S V 


z s 


NEGB RH2 !RH2 = -128; 

COMB RL2 !RL2 = FO,.; 


C Z S V 

I 
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O .COM. 

o. ( RES )FLG flagnames 
SET 


COMFLG, RESFLG, SETFLG 


C Z S P/V D 


Complement/Reset/Set FLA GS Bits 

Each of the FLAGS bits designated in the instruction is comple- 
mented/reset (zeroed)/set in FLAGS. COMFLG leaves H undefined. 


8D 


C Z S op2 


Time (cycles): 7 


op2: 


5: COMFLG 
3: RESFLG 
1: SETFLG 


Example: 


RESFLG P,Z,C,S ! 

COMFLG P,S ! 

SETFLG C,V ! 

COMFLG C,Z,P ! 

RESFLG V,S ! 

C Z S P/V 



128 PROGRAMMING THE Z8000 





9. CP(®)dst, 


src 


• • • • 


C Z S V D H 


Compare 

FLAGS bits are set as they would be for subtracting the source value 
from the destination value. 


mode 

—T— 1 — 1 — 1 —r~ 

op 

1 1 1 1 1 

—1—1—T- 

src 

—1_1_1— 1 

1 1 ■ 

dst R 

_1_1_1_ 


src inodes: 0,4, 8 


OA + W: CP(B) 

10: CPL 

CP(®)(dst = R) 


—T- 

mode 

1 

—1—1—1—1—1— 

oc + w 

» I 1_1_1_ 

—1—1—1— 

dst 

_1_1_1— 

—1— J—l — 

1 

_1_1-1— 


dst modes: 0,4 (not 8) 


CP(B)(dst R,src = #) 


src 



R 

it 

@ 

DA 

X 

CP(B) 

3 

7 

3 

9 

10 

CPL 

1 

8 

14 

14 

15 

16 


Time (cycles) 


dst 

@ DA X 

11 14 15 

Time (cycles) 


Example: rro = 

CPL RR0,RR2 
CPB RH0,RL1 
CP R4,#2 


(-1,-1); RR2 = (0,0); R4 = -32767 ( = 8001,.). 


C Z S V 


! 0 I 1 I 0 I 0 I ! 

C Z S V 

! |o I 0 1 0 I 1 I (-32767 - 2 = 32767)! 

C Z S V 
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10. CP(S)(®)(R)(B) dst, src @R,cnt R,cc 


CPD(B), CPDR(B), CPI(B) CPIR(B), l*l*l*l*l I 
CPSD(B),CPSDR(B),CPSI(B),CPSIR(B) ^ ' s v d h 


Compare (Block) 

The Z bit is set if the combination of FLAGS bits encoded in the cc 
field would have resulted from CP(B) dst, src @R; then the contents of 
the register specified in the cnt field are decremented by 1 and V is set 
if the decremented contents are zero. C and S are undefined. 

Options: 

(S): If S, then dst is @R (compare string); otherwise dst is R 
(compare with constant). 

(^): If D, autodecrement source register after the comparison; 
if I, autoincrement source register after the comparison; 
the change is by ±1 for bytes, ±2 for words. If S, then 
the dst register is also decremented or incremented. 

(R): If R, then repeat the instruction until Z set (a match) or 
V set (cnt decremented to zero); otherwise do the in¬ 
struction just once. 


IK 

Kl 

HU 

B 

B 

B 

B 

0 

_ L-J _ 1 _ 

cnt R 

_ 1 _ 1 _ 1 _ 

dst 

_ 1 _ 1 _ 1 _ 


c 

1 _ 1 

c 

1 _ 1 



dst 


11 + 9n Ml + 14n 


Time (cycles) 


n is the number of times 
the instruction is executed. 


l: D 

R: 

r 

Repeat 

S: 

(l: dst mode = 

(0: I 


\0: 

Do once 

(0: dst mode = 

(hex 8) 


(hex 4) 


(hex 2) 
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Example: RO = 20 ..; R1 = FE..; R 2 = 4; R3 = FS..; R4 = FC,.; R 5 = 2 ; 
data memory: F8 = lOOie; FA = 5; FC = lli*; FE = 20i6. 


CPDR@R0,@R1,R2,LT ! RO = 20,.; R1 = FA,.;R2 = 2; | ' | ° M 

z V 

CPSIR @R3,@R4,R5,EQ ! R3 = FC,.; R4 = 100 ,.; R5 = 0 ; I o I ' I ! 

Z V 


The first terminates because 20i6 < 22i6; the second terminates with 
no match when R5 reaches zero. The use of RO works properly on Z8000 
CPU’s manufactured before July 1980, but see the CAUTION note 
on page 99. 
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11. DAB R 


Cl S V D H 

(See text) 


Decimal Adjust 

A correction factor is added to the contents of the specified byte 
register based upon the assumption that an ADDB or SUBB of unsigned 
2-digit BCD values has just occurred and that a 2-digit BCD represen¬ 
tation of the sum or difference is required. Z and S are set as expected; 
C is set to indicate that the decimal result of the original ADDB or 
SUBB was greater than 99 or less than 0. 


BO 


dst R 


0 


Time (cycles): 5 


Note: The operation relies upon using the C, D and H bits set by the 
ADDB or SUBB (or ADCB,SBCB); so no intervening operations that 
affect C, D or H can occur. 


Example: RHO = 27 ..; RLO = 69,.; RHI = 14..; RLI = 38... 


ADDB RLO, RLI !RL0 = Al,.; RLI = 38,.; 

DAB RLO !RL0 = 7,.; 

ADCB RHO, RHI !RH0 = 3C,.; RHI = 14,.; 

DAB RHO !RH0 = 42,.; 

C Z S V D H 


0 

0 

1 

1 

0 

1 

1 

0 

0 

1 

0 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 


In this case, 2769 + 1438 = 4207, and the final C bit of zero indi¬ 
cates no overflow (i.e., the real result was not 14207). 

Special Note: In CPU’s manufactured before January 1980, the DAB 
instruction may leave S unaffected. 
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12. dst, #n 


DEC(B), INC(B) I l *l* l * l -L- 

C Z S V D H 

(See note) 


Decrement/Increment 

The destination value is decremented/incremented by the specified 
amount n (1 ^ n ^ 16). 


dst 



2A + W: DEC(B) 
28 + W: INC(B) 


Note: (1) The value stored in the instruction is n - 1, not n. 

(2) In assembly language DEC(B) dst or INC(B) dst can be 
written without specifying the value of n; in this case #1 is 
assumed. 

(3) Z and S behave as expected; C is unaffected and V is set 
on overflow. 


Example: RO = 0;R1 = 0;R2 = 100 , 6 ; data memory bytes: FE,6 = 2; FF,6 = 3; 
100,6 = 4. 


LDB RH0,@R2 

!R0 

= 

400,6; R2 

= 100,6 

DEC R2 

!R2 

= 

FF,6; [ 

3 







z 

s 

V 

LDB RL0,@R2 

!R0 

= 

403,6; R2 

= FF,6! 

DEC R2 

!R2 

= 

FE,6; I 

0 

Ijl 






z 

s 

V 

LDB RH1,@R2 

!R1 

= 

200,<; R2 

= FE,6 

LDK R3,#l 

!R3 

= 

1! 




DEC R3,#2 

!R3 

= 

-1; 

"T1 

n 

0 

INC R3,#2 

!R3 

= 

1; 

0 

0 

0 





z 

s 

V 
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13. 



maskbits 


Dl, El 


C Z S V D H 


Disable/Enable Interrupt 

The interrupt enable bits of the FCW are cleared (disable)/set(enable) 
for each interrupt whose mask bit in the instruction is zero. 


7C 


0 0 


Time (cycles): 7 


E/D: 


1 = Enable 
0 = Disable 
(hex 4) 


1: VI not affected 
0: VI affected 
(hex 2) 


jl: NVI not affected 
tO: NVI affected 
(hex 1) 


Example: 

El VI,NVI !VIE & NVIE set in FCW! 

Dl VI ! VIE cleared in FCW; NVIE left set! 
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14. DIV(L) R, src 


• • • • 


S V D H 


(See text) 


Divide 

The destination is a register group twice the size of the source argu¬ 
ment: a register pair for DIV, a quadruple for DIVL. The destination 
value is divided by the source value; the remainder is stored in the high 
order half of the destination, the quotient in the low order half. 

The source and destination values are signed two’s complement 
numbers; the remainder is the same sign as the destination value. 

The FLAGS bits report the outcome of the operation. If V = 0, 
then the operation was completed normally; Z and S reflect the value 
of the quotient. 

If V = 1 and Z = 0, then the source value was zero. The source 
and destination values are left unchanged. 

If V = 1 and Z = 1 and C = 0, then the quotient value is less 
than -2'* or greater than or equal to 2“ (less than -2” or greater 
than or equal to 2” for DIVL). The destination value is undefined. 

If V = 1 and Z = 1 and C = 1, then the quotient value, q, lies in 
the range -2“ < q < -2” or 2” < q < 2“ (-2” < q < -2*' or 
2 ” ^ q 2” for DIVL). The remainder value is stored in the high 
order half of the destination value, and the quotient is represented 
as a two’s complement number by the 17 bits (33 bits for DIVL) con¬ 
sisting of S followed by the low-order half of the destination value. 




? 1— 1 — 

III 

mode 

op 

src 

dst R 


_1_1_1—1—1— 

_L-J_1_ 

» * _ 


src modes: 0,4, 8 


op: 


IB: DIV 
lA: DIVL 
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R 

# 

@ 

DA 

X 

DIV 

95 

95 

95 

96 

97 

DIVL 

723 

723 

723 

724 

725 


src 

R # @ DA X 


13 

13 

13 

14 

15 

30 

30 

30 

31 

32 


Abort: src = 0 
Time (cycles) 


src 

R # @ DA X 


25 

25 

25 

26 

27 

51 

51 

51 

52 

53 


Abort: src too 
small 


Example: RO = -1;R1 = -31;R2 = -1;R3 = -50;R4 = 2; R5 = 
- 32768; R6 = - 1. 


DIVL RQ0,RR4 !R0 = 2; R1 = 32,718; R2 = -13; R3 = -1; R4 = 2; 
R5 = -32768; o o i o ! 

c z s V 

DIV RR4, R6 !R4 = ?; R5 = ?; R6 = -1; | o | o | i | i | ! 

c z s V 

The first case shows -(15x2^^ + 50) -j- (5x 2‘0 = -3x2** with 
remainder - 50; the second divide is aborted because the divisor is too 
small. 

Special Note: In CPU’s manufactured before January 1980, V may 
not be set properly; also, division by zero may cause the next instruction 
to be executed improperly. 
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15 . D(B)JNZ cnt R, dst 


C Z S V D H 


Decrement and Jump if Non-Zero 

The register specified in the cnt field is decremented by 1; if the result 
is non-zero, the destination address replaces the PC contents, i.e., a 
jump back to dst occurs. 


—1—1—1— 

F 

—1—1—1— 

cnt R 

W 

—1—1—1—1—1—1— 

dst displacement 

_1_1_1— 

__i_1_1_ 


_1_1_1_1_1_1_ 


Time (cycles): 11 


The destination address is computed as follows: the displacement is 
taken as an unsigned (positive) 7-bit value, multiplied by 2, then sub¬ 
tracted from the address of the location following the D(B)JNZ. (So 
D(B) JNZ can be used to transfer to addresses in the range $ - 252 to $ -h 2.) 


Example: The following code uses RHO as a loop counter, RHl as 
an accumulator and R1 as a pointer to the data memory byte array 
BYTAR. The four values at BYTAR, BYTAR + 1, BYTAR + 2 and 
BYTAR -h 3 are added into RLO and then the program halts. 


LDB RHO,#4 
CLR RLO 
LDA Rl, BYTAR 
LOOP: ADDB RL0,@R1 
INC Rl 

DBJNZ RHO,LOOP 
HALT 


!Set loop counter! 

! Clear accumulator! 
!Set pointer! 

! Add in next byte! 

! Increment pointer! 


Special Note: In CPU’s manufactured before January 1980, DJNZ 
may not work. 
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16 . EX(B) R, 


src 


C Z S V D H 


Exchange 

The source and destination values are exchanged. 


src modes: 0, 4, 8 {not tf) Time (cycles) 

Note: The src modes are handled like dst modes (no #), since each 
argument is both source and destination. 

Example: RO = Ris = lOO,*; stack memory: 100,6 = 1234,6. 
EXBRL0,@R15 !R0 = 12,6; R15 = 100,6; 100,6 = 1734,6! 


—1— 

mode 

__l_ 

—1—1—1—1—1— 

2C + W 

_1_1_1_1_1_ 

-!-1-1- 

src 

_1_1 « 

—!-1—1— 

dstR 

_1_1_1_ 


src 

R @ DA X 


□ 

12 

15 

0 
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17 . EXTS(®) R 


Extend Sign 

The high order bit (sign bit) of the low order half of the destination 
value is copied into each bit of the high order half. The destination 
register specified is twice the size normally implied by the ending of 
the instruction mnemonic (e.g., EXTSB RO, EXTS RRO, EXTSL RQO). 


-1- 1-1 - 1-1-!-1— 

- 1 — 1 — 1 — 

— 1 - 1 — 1 - 

B1 

_1—1— 1 — 1 — 1— — 1 —1 

dst R 

_ 1 _ 1 _ 1- 1 

size 


Time (cycles): 11 



0: EXTSB 



size: 

A: EXTS 




7: EXTSL 



Example: ro = 

-1;R1 

= -50; 


DIV RR0,R2 

!R0 = 

0; R1 = 


EXTS RRO 

!R0 = 

-1; R1 


DIV RR0,R2 

!R0 = 

-1;R1 


.2 = 2 . 

25; R2 = 2! 
-25; R2 = 2! 


As illustrated here, the result of a division is only half the size re¬ 
quired for the dst argument of a divide instruction; EXTS provides the 
means of replacing an argument by an identical value with twice the 
number of bits. 
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18 . HALT 


I I I I I I ] 

C Z S V D H 


Halt the CPU 

Cease CPU instruction execution until an interrupt or a RESET is 
received. The CPU continues to respond to BUSRQ and generates a 
continuous stream of refresh cycles using the REFRESH register’s 
ROW field. It can respond to interrupts every 3 clock cycles, since a 
refresh cycle is three clock cycles long. 


1 —i—I—I—I—I—I—I—I—I—I—I—I—I—r 

7A00 

J_I_I_I_I_I_I_I_I_I_I_I_« « » 


Time (cycles): 8 + 3n 
n = number of refresh cycles 
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19 . (S)( dst, 


src 


IN(B), OUT(B), SIN(B), SOUT(B) L I I I I I 

C Z S V D H 


Input/Output 

A transfer of data is made between the specified CPU register and 
the specified 16-bit address in I/O address space. The transfer is to the 
CPU register for (S)IN(B) and from the register for (S)OUT(B). 

The S denotes “special” I/O; these are identical to regular I/O except 
for different status on pins ST 3 - STo (see Figure 2 . 12 ); they are intended 
for use with the MMU. 


op 


l/0@R 


CPU R 


Time (cycles): 10 


op: 


3C + W: 
3E + W: 


IN(B); I/0@R = src; CPU R = dst 
0UT(B);I/0@R = dst; CPU R = src 


op2 

-I_ \ i- 


3A + W 

-J_I_L_ 


Time (cycles): 12 


op2; 


4 

5 

6 
7 


IN(B) ) 
SIN(B)) 
OUT(B) 1 
SOUT(B)) 


CPU R 

CPU R 


dst; src mode = DA 
src; dst mode = DA 


Example: rlo = 41,6 ; ri = 1000 ,,; r 2 = looii,. 


WAIT: 


INB RH0,@R1 
TESTB RHO 
JR PL,WAIT 
OUTB @R2,RL0 


!Get “status” from I/O adr 1000,5! 

!1NB does not set FLAGS bits ! 

IWait for “ready” bit in bit 7 ! 

IThen put out ASCII “A” to I/O adr 1001, J 
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20. (S)(quj*)(^(R)(b) dst@R, src@R, cnt R 






C Z S V D H 

(See text) 

IND(B), INDR(B), INI(B), INIR(B), 

SIND(B), SINDR(B), SINl(B), SINIR(B), 

OUTD(B), OTDR(B), OUTI(B), OTIR(B), 

SOUTD(B), SOTDR(B), SOUTI(B), SOTIR(B) 


Input/Output (Block) 

A data transfer occurs between an external location (in I/O address 
space) and an internal location (in data address space); then the contents 
of the register specified in the cnt field are decremented by 1; V is set if 
the resulting contents are zero. Z is undefined. 


Options: 

(S): If S, then “special” I/O, otherwise normal I/O. (See 
Description 19.) 

^OUT*^* source is an external address, and the destination 

is an internal address; if OUT, then vice versa. 

(^): If D then autodecrement the internal address register after 
the transfer; if I, then autoincrement. Change is by +1 
for bytes, + 2 for words. 

(R): If R, then repeat the instruction until cnt = 0; otherwise 
do it just once. 


—1 — 1 — 1 — 1 — 1 — 1 —I— 

3A + W 

—1-1—1- 

src @R 


0 

O 

3 

""'"T T.T 111 

0 cnt R 

—i— 1 — 1 - 1 - 1 - 1 — 

dst @R 

R 



Time (cycles): 11 + lOn 
n is the number of executions 
(n = 1 if not R). 


— ( 0 = repeat _ • 1 = decrement I 1 = output 

R: / D/I: / 0/1: < 

( 1 = do once I ® ~ increment i ® ~ input 

(hex 8) (hex 8) (hex 2) 

*Note: OUT is shortened to OT in some assembly mnemonics. 


S: 


1 = special 
0 = not special 
(hex 1) 
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Example: RO = 6; R1 = lOOOie; R2 = FF,6; R3 = IOOI 16 ; data memory bytes; 
FA = 21; FB = 4F; FC = 4C; FD = 4C; FE = 45; FF = 48. 


WAIT; INB RH4,@R1 
TESTB RH4 
JR PL,WAIT 
OTDB @R3,@R2,R0 
JR NOV,WAIT 


!“Status” from I/O adr 1000^! 

!INB will not set FLAGS bits! 

!Wait for “ready” bit in bit 7! 

!Output another character of “HELLO!”! 
!More to come if V not set! 


Z8000 INSTRUCTION SET 143 



21 . IRET 


C Z S V D H 

(Restores saved versions) 


Interrupt Return 

Using the system stack register (RR14 or R15), one word (the 
“reason”) is popped and discarded; the next word is popped into the 
FCW; finally an address is popped into the PC. 


I I I I I 

7B00 


Z8001 Z8002 


16 


13 


Time (cycles) 


Note: The address popped into the PC by IRET is one word or two, 
depending upon the segmentation mode in which the processor is execu¬ 
ting. Care must be taken when using a Z8001 in non-segmented mode, 
since the address saved on the stack by the Z8001 when an interrupt or 
trap occurs is always in the segmented format, regardless of the seg¬ 
mentation mode in which it is running when the interrupt or trap occurs. 


Example. RR14 = (700 i6,FA,6); pc = (600i6,104Fi 6); stack memory locations 
in segment 7, starting at offset FA^: FA,6 = 7F07,6; FC,6 = 18A0,6; FE,6 = 400,6; 
100,6 = FF4,6;NSPSEG = 400,6; NSPOFF = 2000,6. 


IRET !PC = (400,6, FF4,6); R15 = 2000,6; FCW is set to non-segmented, 
normal mode with 1 1 j o | 1 1 o| o| o| and VI, NVI enabled! 

C Z S V D H 
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22. (J^) cc, dst 


C Z S V D H 


Jump (conditionally) 

If the combination of FLAGS bits encoded by the cc field is true, 
then the address (N.B.: not the value) of the destination replaces the 
PC contents. 






@ 

DA 

X 

mode 

1 ! 1 -1~—1— 

IE 

1 11 1 -j... 

— 1 —1—1— 

dst 

-1-!-1 

CC true 

10* 

7 

8 


cc false 

7 

7 

b] 


dst modes: 0,4 (not 8) 
JP 


Time (cycles) 

*15 in segmented mode 


E 


cc 


dst displacement 


JR 


Time (cycles): 6 


For JR the destination address is computed as follows: the displace¬ 
ment is taken as a signed 8-bit value, multiplied by two, then added to 
the address of the location following the JR. (So JR can be used in the 
range $ - 254 to $ -l- 256.) 


Note: (1) JR will never change the segment part of the address. 

(2) An unconditional jump can be specified in assembly 
language by JR dst or JP dst. 

Example: The program segment 

If RO > 5 then (action 1) else (action 2) 

can be implemented by 

CP R0,#5 
JR LE,ELSCOD 
(instructions for action 1) 

JRENDSEG 

ELSCOD: (instructions for action 2) 

ENDSEG: (continuation of the program) 
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23 . ld(®) dst, src 


C Z S V D H 

(Note: none affected) 


Load 

The source value replaces the destination value. 


mode 

— 1—1 - 1—1—1— 

op 

_1_L—J-1-1- 

“T- 1 — I — 

src 

_1_l—J— 

—1 - 1 —1— 

dstR 


src modes: 0,4, 8 


20 + W: LD(B) 

14: LDL 

LOAD to REGISTER 


src 



R 

ft 

@ 

DA 

X 

LD(B) 

3 

7 

7 

9 

10 

LDL 

5 

11 

11 

12 

13 


Time (cycles) 


C dst R 


#src 


STREAMLINED LOAD 
BYTE IMMEDIATE to REGISTER 


— 1 — 

mode 

— 1 — 1 - 1 — 1 — 1 — 

op 

— 1 — 1 — 1 — 

dst 

—1—1—1— 

— 1 — 1 — r“ 

src R 


dst modes: 0,4 (not 8) 


op: 


2E + W: LD(B) 
ID: LDL 


Time (cycles): 5 


dst 

@ DA X 


LD(B) 

LDL 

Time (cycles) 




12 

7? 

14 

15 


LOAD from REGISTER 


dst 

DA X 


mode 

—1 — 1 — r— 1— f —I 

oc + w 

—!-1—1— 

dst 

—1-1—1— 

5 

0 

14 1 15 1 

_J_ 

_ 1 _L—J_ 1 — 1 — 

—J—J_1_ 

» • « 



dst modes: 0,4 (not 8) 


LOAD IMMEDIATE to MEMORY 
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■ "I 1—1—r • r—7—1— 

op 

— 1— I —1— 

Bose R 

—1— 

acc R 

LD(B) 

14 

—1—1—1—1—1 1 1 1 1 1-1—1- 

T6-bit offset 

^ _ 1 _ 1 _ 1 _ 1 _ 1 _i_ «««»»««» 

LDL 

17 


op: 


30 + W; 

35: 
32 + W: 
37: 


LD(B) ) 
LDL f 
LD(B) ) 
LDL j 


acc R is dst 

acc R is src 


Time (cycles) 

Base R 0; dala adr = Base R + offset 


BASE ADDRESSED LOAD 


o 

— 1 —1—1— 

P 

— T -1 1 

Bose R 

acc R 

0 

1 1 ■ 

1 1 t 

Offset R 

i i 1 

1 1 1 

0 

_i_1_1_ 

1 I 

0 


LD(B) 14 
LDL 77 

Time (cycles) 


op: 


70 + W: LD(B) ) 
75: LDL ) 
72 + W: LD(B) ) 
77: LDL ) 


acc R is dst 


acc R is src 


Base R 9 ^ 0; data adr = Base R -l- Offset R 


BASE INDEXED LOAD 


Note: The assembler always generates the streamlined form of 
LDB R,#src. 


Example: RO = O; R1 = lOOu; R2 = 4; dala memory 100,< = 0; 102,< = 22; 
104,. = 44. 

LD RO, Rl(«i'2) !R0 = 22! 

LDRO, R1(R2) !R0 = 44! 
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24 . ( 


LDA 

LDAR 


) R, 


src 


C Z S V D H 


Load Address 

The address (not the value, as with most instructions) of the source 
replaces the destination value. The destination is a register in non- 
segmented mode, a register pair in segmented mode. 

In the segmented case, the high order bit and the “reserved” low 
order byte of the segment word are zero for LDAR, undefined for LDA. 

For LDAR the address of the source is computed as follows: the 16- 
bit signed displacement is added to the address of the location following 
the LDAR instruction. The segment portion of the address is not affected 
by this computation. 


src 


—1-1—1—1—1—1— 

mode 36 

_1_1_1_1_1_L 

-1—1—1- 

src 

—1—1—1— 

dstR 


12 13 

src mode = 4 only 

LDA (DA and X MODES) 

Time (cycles) 

I 1 1 I 1 1—1 

34 

_1_1_1_1_1_1_1_ 

Bose R 

—1—1—1— 

dst R 

1 1 1 

Time (cycles): 15 

i 1 1 I 1 1-1-1—1—I—n 

16-bit offset 

—1—1—1—1-1—1-1—1_1_1_1_ 



LDA (BASE ADDRESSED MODE) 


—1—1—1—1 

7 

1—1—1—1- 

4 

—1—1—1— 

Bose R 

—I—1—1— 

dst R 

0 

_1_1_1_ 

1 If' 

Index R 

I 1_1_ 

1 1 1 

0 

_1_1_ 

1 1 1 

0 

_L_l_ 


LDA (BASE INDEXED MODE) 


Time (cycles): 15 


Note: Base R cannot be zero. 
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Time (cycles); 15 


—T—1—1—1—1—1—1- 

34 

— 1 -,-, — 

0 

-1—1—1— 

dstR 

—1—1—1-1—1—1 1 1 1 1 1 

src displacement 

—J_L—l_1_1_1-1-1-1-1-1-1 

III 

1_1—1—1— 


LDAR 


Example: Array of text characters at data memory address MESG. 
This code will output them using the subroutine OUTCH. 


LDA R3,MESG 
LOOP; LDB RL0,@R3 
INC R3 
TESTB RLO 
JR Z,DONE 
CALL OUTCH 
JR LOOP 

DONE; 


! Address of text array to R3 ! 

!Get next text character ! 

! Point to following character ! 

!Zero character terminates! 

! Output character from RLO ! 

!Go back to do the next character ! 
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25 . LDCTL(B) dst, src 


C Z S V D H 

(See text) 


Load Control Registers 

The contents of the specified control register are transferred to or 
loaded from the specified accumulator. FLAGS bits are affected only 
if the dst is FCW or FLAGS (they are loaded from the source). 


T-1—I 

acc R 


“T-1“ 

CTLR 


Time (cycles): 7 


( 8C: LDCTLB (only used with FLAGS) 

(7D: LDCTL 

! 1: acc R is src CTLR: 

0: acc R is dst 
(hex 8) 


1: FLAGS 
2: FCW 
3: REFRESH 
4: PSAPSEG 
5: PSAPOFF 
6 : NSPSEG 
7: NSPOFF 


Note: (1) PSAPSEG and NSPSEG may not be used on the Z8(X)2. 

The assembler will recognize mnemonics PSAP and 
NSP for PSAPOFF and NSPOFF. 

(2) Reserved (or unused) bits of the control registers are 
transmitted as zeroes from the control register; they are 
ignored when transmitted to the control register. 


Example: The program needs to change the program status address 
pointer to refer to a table at location NEWSTAT. 


LDA RR12,NEWSTAT 
LDCTL R11,FCW 
DI NVI,VI 

LDCTL PSAPSEG,kl2 
LDCTL PSAPOFF, R13 
LDCTL FCW,R11 


!Get the desired address ! 

!Save flag-control word ! 
!Mask all maskable interrupts ! 
!Set the segment! 

!Set the offset! 

IRestore FCW! 
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This sequence is still vulnerable to the occurence of the NMI between 
the setting of PSAPSEG and the setting of PSAPOFF, but it protects 
against any other interrupts during the changing of the program status 
address pointer. If the NMI occurs at the critical moment this program 
will probably crash; one solution to this would be to give all program 
status areas the same segment or the same offset. 

Special Note: In CPU’s manufactured before July, 1980, the instruction 
LDCTL R, REFRESH results in reading undefined values for the RE 
and RATE fields. 
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26 . LD(y)(R)(B) dst@R, src@R, cnt R 


LDD(B), LDDR(B), LDI(B), LDIR(B) L 1 * 1 T l I I 

C Z S V D H 

Load (Block) 

The destination value is replaced by the source value, and the register 
specified in the cnt field is decremented by 1; V is set if the result of 
decrementing is a count value of zero. Z is undefined. 

Options: 

(^): If D, autodecrement src and dst registers; if I, autoincrement. 

The change is by ± 1 for bytes, ± 2 for words. 

(R): If R,then repeat the instruction until cnt = 0; otherwise do 
the instruction just once. 


Time (cycles): 11 + 9n. 

n is the number of executions 
(n = 1 if not R). 


—!—1—n 

BA H 

1 1 1 

—r-T—1— 

h w 

1 1 1 

—1-1—1— 

src @R 

1 1 1 

D 

/ 

1 

—1—1— 

1 

1 1 

til 

0 

_1_1_1_ 

1 1 1 

cnt R 

_1_l_l_ 

1 1 1 

dst @R 

_1_1_1_ 

R 

1 1 

0 

_l—J_ 


! 1 : decrement 
0 : increment 
(hex 8) 


! 0 : repeat 
1 : do once 
(hex 8) 


Note: If the source and destination address ranges overlap, then either 
autoincrementing will fail and autodecrementing will work or vice versa; 

the key is to move data/rom the overlapping area before moving data 
to it. 


Example: Data memory: F0,6 = 1000; F2,6 = 2000; F4,6 = 3000; E0,« = 1100; 
E2i6 = 2200; E4,6 = 3300; R1 = F0,«; R2 = EO,*; RO = 3. 

LDIR @R1,@R2,R0 !R1 = FO,*; R2 = EO,*; RO = 0; 

V = 1; memory: FO,*, EO,* = 1100; 

F2.6,E2,, = 2200; F4,6,E4,6 = 3300! 
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27 . LDK R,#n 


C Z S V D H 


Load (Small) Constant 

The destination value is replaced by the number n (0 4 n ^ 15). 


BD 


dstR 


#n 

i I 


Time (cycles): 5 


Example: 

LDK R0,#5 !R0 = 5 ! 

By comparison, LD R0,#5 requires 4 memory bytes instead of the 
two for LDK, and it takes 7 cycles instead of 5. 
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28 . LDM dst, src, #n 


C Z S V D H 


Load Multiple 

n (1 4 n 4 16) word registers consecutively numbered (mod 16), 
starting at the one specified in the instruction, are loaded from or to a 
block of n words of memory whose initial address is specified in the 
instruction. 


—1— 

mode 


—1—1—1— 

1C 

—1-1-1- 

mem 

—1—1-1— 

op2 

1 

( 

_l_J 

) 

1 1 1 

R 

_1_!_1_ 

1 1 1 

0 

_ 1 _I_ 1 _ 

1 1 1 

#n-l 

_1_1 1 


mem modes: 0,4 (not tt, not 8) 


op2: 


9: R is src, mem is dst 
1: R is dst, mem is src 


mem 

@ DA X 


11 + 3n 


14 + 3n 


15 + 3n 


Time (cycles) 


Note: “Consecutively numbered (mod 16)” means that RO follows R15. 


Example: RO = 7; R 1 = IS; R 2 = fa,.; R14 = 9 ; R 15 = 10 . 


LDM @R2,R14,#4 iRegisters unchanged. Data memory: 

FA,. = 9;FC,. = 10; FE,. = 7; 100,. = 15! 
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29 . LDPS src 


C Z S V D H 

(Loaded from source) 

Load Program Status 

The program status located in data memory starting at the source 
address is loaded into the CPU’s FCW and PC. 

The format of the program status in memory depends upon the SEG 
status in the FCW before the LDPS is executed, regardless of the SEG 
status in the FCW loaded by the instruction. 

If non-segmented, the program status consists of two words: the 
FCW followed by the PC. If segmented, it is four words: a zero word, 
the FCW, then the 2-word PC. (See Figure 2.6.) 


non-seg. 
seg: short adr. 
seg: long adr. 

Time (cycles) 


mode 

■ 1 

—1-1—I—\—1— 

39 

_1_1—1—1— 

—1-1—1— 

src 

_1_1-1— 

1 1 1 

0 

—1_1_1— 


src modes: 0,4 (not 8, not if) 


src 

@ DA X 


12 

16 

17 


20 

20 

16 

22 

23 


Example: Program is running in non-segmented mode and needs to 
enter segmented mode (perhaps to call a subroutine in another segment). 


LDAR R0,XYZ 
PUSH @R15,R0 
LDCTL R0,FCW 
SET R0,#15 
PUSH @R15,R0 
LDPS @R15 


!Get desired PC value ! 

!Save it on the stack ! 

!Get current FCW ! 

!Set bit 15—SEG status ! 

IPush onto the stack ! 

!Load newly constructed program status—execution con¬ 
tinues at XYZ of the current segment, in segmented mode ! 


Z8000 INSTRUCTION SET 155 




30 . ldr(®) dst, src 


:n : i i i i 

C Z S V D H 


Load Program Constant 

A transfer is made between the specified register and a location in 
program address space (not data address space). 


— 1 — 1 — 1 — 1 — 1 — 1 — 1 — 

op 

i II 1 1 1 1 

— 1 — 1 — 1 — 

0 

— 1— 1 —1— 

R 

1 It 1 1 1 1 

displac 

— 1 -1 — 1-1—1_1_1_1 

r 1 1 1 

:ement 

1 1 1 


LDR(B) 

LDRL 

Time (cycles) 


14 

17 


op: 


30 + W: 

LDR(B) 

35: 

LDRL 

32 + W: 

LDR(B)] 

37: 

LDRL 1 


R is dst, program constant is src 


R is src, program constant is dst 


The program constant address is computed as follows: the displace¬ 
ment as a 16-bit signed number is added to the address of the location 
following the LDR instruction. This will never affect the segment 
portion of the address. 

Example: A disk diagnostic program is written with a few key para¬ 
meters assembled into locations in one place (rather than being spread 
all over the program as immediate arguments) so that they can be 
“patched” in the field to adapt to different controller versions or to 
allow variations in the testing pattern. 

TRACKS: 77 

SECTORS: 32 
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A subroutine needing to refer to these (which have to be in the same 
segment) would have code like: 

LDRRO, TRACKS !R0 = 77! 

LDR Rl, SECTORS !R1 = 32! 
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31 . m(res) 

SET 

MBIT, MRES, MSET 


n*: H 11 1 

C Z S V D H 

(See text) 


Multi-Micro Test/Reset/Set 

MBIT tests the MI input, clears S if the i nput is set and leaves Z un¬ 
defined. MRES and MSET reset and set the MO output; they leave the 
status bits unaffected. 


-1—1-l—T 

7B 

—1-1- 

—r-i 1 

0 

— l—T — 1 — 

op2 

.. i 1 1 1_L 

_L-J_ 

-A 1_1_ 

_1_1_L. 


f A: MBIT 
9: MRES 
8 : MSET 


MBIT 7 
MSET/MRES T 

Time (cycles) 


Example: (See instruction Description 32: MREQ instruction.) 
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32 . MREQ cntR 






C Z S V D H 


Multi-Micro Request 

Conduct the multi-micro request protocol using the propagation 
delay time constant contained in the register specified in the cnt field. 
Set Z if acquisition was attempted; set S also if acquisition succeeded. 

The protocol, which requires external logic and a bus to implement 
a daisy chain, works as follows: _^ 

(1) If Ml = 1 (resource in use), set MO = 0 and terminate in¬ 
struction with Z = 0 and S = 0. _ 

(2) If Ml = 0 (resource may be available), set MO = 1; then 

decrement cnt to zero (7 c^s per decrement). 

(3) If Ml = 1 (signal from MO not blocked on daisy chain), ter¬ 
minate instruction with Z = 1, S = 1 (acquisition succeeded). 

(4) If Ml = 0 (signal was blocked), set MO = 0 and terminate 
instruction with Z = 1,S = 0 (acquisition tried, but failed). 

Time (cycles): 12 -i- 7n 

—I—I—I—' ' ' ' ' ' ' ' ' ' n is the number of times 

7B cntR D . j n 

....... I ... I ... I cnt IS decremented (n = 0 

if acquisition not attempted). 


Example: 

WAIT: MBIT 

JR PL,WAIT 
LDK R0,#20 
MREQ RO 
JR MI,USE 
MRES 
JR WAIT 

USE: (use the resource) 

MRES 


ITestMl! 

IWait until success is likely! 

! Allow 35 jits propagation delay (at 4 MHz)! 
!Do the protocol! 

!If success, use it! 

!Else clear ^! 

!Try again! 

! Clear MO—release the resource! 
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33 . MULT(L) R, src 


C Z S V D H 

(See text) 


Multiply 

The destination is a register group twice the size of the source argu¬ 
ment: a register pair for MULT, a register quadruple for MULTL. 
The low order half of the destination value is multiplied by the source 
value and the product replaces the destination value; all are taken as 
signed two ’ s complement numbers. 

Z and S are set as expected; C is set if the product is less than — 
(-2^' for MULTL) or greater than or equal to 2*^ (2^* for MULTL); 
V is always cleared. 


—1— 

mode 

_1_ 

—1-1—1 1—1— 

op 

—1-1 1 1 1 

—1—1—1— 

src 

-1-1_1_ 

—1—1-1— 

dstR 

_1_1_1_ 


src modes: 0,4,8 


19: MULT 
18: MULTL 

src 

R ^ @ DA X 

MULT 
MULTL 

Time (cycles) 
src value # 0 


70 

70 

70 

71 

72 

282+ 7n 

282-|-7n 

282+ 7n 

283+ 7n 

284+ 7n 



src 


R 


@ 

DA 

X 

18 

18 

_ _| 

18 

19 

20 

30 

Zl 

~3^ 

31 

32 


Time (cycles) 
src value = 0 


n is the number of non-zero bits in the magnitude of the low order half of the 
destination value. 
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Example: RO = 99;R1 = 99;R 2 = -2;R3 = 0;R4 = 1;R5 = 16. 


MULTLRQ0,RR4 !RO = -1;R1 = -3;R2 = -32;R3 = 0; 

R4 = 1;R5 = 16; | i | o | i | o| ! 

C Z S V 


In this example, -2'^ x (2“ + 2‘) = -(2” + 2^■); note that the 
original values of R0,R1 are irrelevant. The time required for the exe¬ 
cution of this instruction is 282 -1- 7 = 289 cycles, since 2’’ has one 
non-zero bit. 

Special Note: In CPU’s manufactured before March 1980, MULTL 
may fail when the REFRESH register operation is enabled. 
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34. NOP 


Z S V D H 


No Operation 

The CPU does nothing for 7 cycles. 


T I I r~i I I I I I I r~i—I—r 

8D07 

J—I—I 1—I—I—I—I—I I I I I I L 


Time (cycles): 7 


Note: NOP has two main uses: providing the “body” of timing loops 
and filling the place of “patched out” instructions. 

Example: 


NOP 

!7 cycles! 

NOP 

!7 cycles! 

NOP 

!7 cycles! 

NOP 

!7 cycles! 

DJNZ R0,LP 

!11 cycles! 


This loop will take 39n cycles to execute, where n is the initial value of 
RO, taken as an uns/gnerf positive number from 1 to 2'^ (i.e., RO = 0 
means the loop will be executed 2'* times). This gives a range of 9.75 /xs 
to about 639 ms using a 4 MHz clock; more NOP’s would give a longer 
maximum delay but with coarser granularity. 
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35. POP(L)dst, @R 



Pop from Stack 

The value of the location addressed by the source register (stack 
pointer) replaces the destination value; then the source register is in¬ 
cremented by the number of bytes transferred (2 for POP, 4 for POPL). 
(See Figure 2.2.) 

dst 

R @ DA X 

POP 
POPL 

Time (cycles) 

j 17: POP 
115: POPL 

Note: (1) For POPL, the stack pointer used in the src field cannot 
also be used in the dst field, e.g., POPL RR4,@R4 is illegal. 

(2) The autoincrement of the source register occurs last, after 
all of the address computations and the data transfer. 

F.xannplP! R6 = FA,,; Data memory FA„ = 1111; FC,, = 2222; FE„ = 3333. 

LD R0,2(R6) !R0 = 2222; R6 = FA,.; memory unchanged! 

POP2(R6),@R6 !R0 = 2222; R6 = FC,.; FA,. = 1111; FC,. = 1111; 

FE,. = 3333! 




dst modes: 0,4,8 
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36. PUSH(L) @R,src 


C Z S V D H 


Push onto Stack 

The destination register (stack pointer) is decremented by the number 
of bytes to be transferred (2 for PUSH, 4 for PUSHL); then the source 
value replaces the value of the memory location addressed by the new 
value of the destination register. (See Figure 2.2.) 


—1— 

mode 

_ 

—1—1—1—n— 

op 

—1-1_1_L—l_ 

“T-1-1— 

dst @R 

—1_1_1 

—1—1—1— 

src 


src modes: 0,4,8 
(not #) 


13: PUSH 
11: PUSHL 

PUSH(L)—srcnot# 



R 

@ 

DA 

X 

PUSH 

9 

_i 

13 

14 

14 

PUSHL 


20 

21 

21 


Time (cycles) 


OD 


III III 

dst@R 9 


Time (cycles): 12 


PUSH immediate 


Note: (1) For PUSHL the stack pointer register used in the dst field 
cannot also be used in the src field, e.g., PUSHL @RR6, @RR6 
is illegal. 

(2) The autodecrement of the destination register occurs 
after any address computations but before the data transfer. 
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Example: R6 = FC,«; RO = 2222 ; Data memory FA,, = 0000; FC,* = 1111; 
FEu = 3333. 

PUSH @R6,@R6 !R6 = FA,«; memory FA.s = 1111; FC,, = 1111; 

FE.5 = 3333! 

LD 2(R6),R0 !R6 = FA.^; RO = 2222; memory FA,* = HH; 

FC,. = 2222; FE.. = 3333! 
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37. RET cc 


C Z S V D H 


Return from Subroutine 

If the combination of FLAGS bits encoded by the cc field is true, 
then the PC (two words if segmented operation, one if non-segmented) 
is popped from the stack controlled by the implicit stack register (RR14 
orRlS). 


non- 
seg. seg. 

cc false 
cc true 


7 

7 

10 

13 


Note: (1) The use of this instruction assumes a prior CALL, CALR 
or equivalent to place an address on the stack in the proper format. 
(2) RET can be written without a cc field, in which case the 
return happens unconditionally. 

Example: The numbers in the comment field indicate the sequence 
of instructions executed; 


CALL XYZ 

!1! 

HALT 

!4! 

NOP 

!2! 

RET 

!3! 
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38. r(®)(C)(b) r, #places 

RL(B), RLC(B), RR(B), RRC(B) 


• • • • 


C Z S V D H 

(See below) 


Rotate Right/Left 


The destination register is regarded as a circle of 1-bit registers with 
the high order bit (7 or 15) one place to the right of bit 0. If C is included 
it is treated as one more 1-bit register, lying between bit 0 and the high 
order bit. The circle is rotated left or right by the number of places 
specified (1 or 2). 

If C is not included, it is nonetheless set to the last value to pass be¬ 
tween the high and low order bits. 


—1—1—1—1—1—1—1— 

—1-1—1— 


R 



B2 + W 

1 « «_1_1_1_1— 

dstR 

__l_1_1_ 1 

111 

/ 

L 

P 

0 


1 2 
place places 


6 7 


Time (cycles) 


1 = include C 
0 = do not 
(hex 8) 



(hex 4) 


1 = 2 places 
0 = 1 place 
(hex 2) 


Note: (1) C is affected as noted above; Z and S are set to reflect the 
result; V is set if the sign of the destination value changes. 

(2) If #places is omitted in the assembly language designation, 
#1 is assumed. 

Example: ro = afos... 


RLB RH0,#2 

!R0 = BEOS,.; 

0 

0 

1 

0 

RRRO 

!R0 = DF02,.; 

1 

0 

1 

0 

RLCB RL0,#2 

!R0 = DFOA,,; 

0 

0 

0 

0 

RRCB RHO 

!R0 = 6F0A,.; 


0 

0 

1 

RLC R0,#2 

!R0 = BC2A,.; 


1 

1 



c 

z 

s 

V 
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39. r(J[)db dst R, src R 

RLDB, RRDB 1 1*1*1 I I 

C Z S V D H 


Rotate Digits Between Bytes 

The two digits of the source register and the low order digit of the 
destination register are taken as a circle of digits and rotated one place 
to the left or right. Z is set if the final destination value is zero. S is 
undefined. 


—i—r 

op 


I —n 

src R 


T -l I 

dst R 


Time (cycles): 9 


op: 


BE: RLDB 
BC: RRDB 


Note: The source and destination byte registers must not be the same. 


Example: ro = abcd,<; ri = efi 2 ,.. 



RLDB RL1,RH0 

!R0 = B2CD; Rl = EFIA; 

0 

0 

RLDBRHO.RLO 

!R0 = BCD2; Rl = EFIA; 

0 

1 

RLDBRL0,RH1 

!R0 = BCDE;R1 = F21A; 

0 

1 

RLDB RHl.RLl 

!R0 = BCDE;R1 = F1A2; 

0 

1 

RRDB RL1,RL0 

!R0 = BC2D; Rl = FIAE; 

0 

1 

RRDB RHO.RHl 

!R0 = B12D; Rl = CFAE; 

0 

1 



z 

s 


168 PROGRAMMING THE Z8000 





40. sc# index 


C Z S V D H 

(Set from PSA) 


System Call 

The system call trap occurs; the instruction becomes the reason. 
The index field in the low order byte of the reason allows a software 
routine selection analogous to the vectored interrupt. 

non- 
seg. seg. 


I—I—I—i—I—I—I—i—J—•—I—•—i—I—I—«—I Time (cycles) 

Example: FCW = 8000 »; pc = ( 300 ,., 200 ,.); RRM = ( 500 , 6 , 100 ,.); 

system stack pointer = (600,6,60,.). 

SC #7 !FCW,PC loaded from PSA (see Figure 2.9); 

NSPSEG = 500,.; NSPOFF = 100,.; RR14 = (600,6,BA,6)*; 
Stack memory in segment 6: BA,. = 7F07,.; BC,. = 300,.; 

BE,. = 202,.! 


*assuming FCW from PSA has system mode set 


Z8000 INSTRUCTION SET 169 




41 



C Z S V D H 


SDA( J), SDL(g), SLA(g), SLL(g), SRA( J), SRL(g) 


Shift 

The contents of the destination register are shifted according to the 
direction and number of places specified in the source value. 

For a left shift, vacated low order positions are filled with zeroes, 
while the last bit shifted from the high order end is used to set C. For 
the right shift, C is set from the last bit shifted from the low order end; 
filling of vacated high order bits is with zeroes for a logical shift or 
with the original sign bit for an arithmetic shift. 

A negative source value indicates a right shift; positive indicates a 
left shift; the magnitude is the number of bits to shift. If the magnitude 
exceeds the number of bits in the destination register, the operation is 
undefined; iFzero, then no shift occurs. 

Z and S are set according to the final destination value (even for a 
zero source value); C is set as described above; V is undefined for logical 
shifts, cleared for arithmetic right shifts and set for arithmetic left 
shifts if the initial and final destination values have different signs. 


op: 


-I-1_I_» » ■ 


r 

lB3: 


(L/W = 0): byte 
(l/W = 1 : long-word 
(L/W = 0: word 
(hex 4) 


1 1 r 1 1 1 1 

op 

_1 _ 1_1_1 _ 1_ L_1_ 

—1-1—1— 

dstR 

_ ■ _ L 1 

A 

/ 

L 

L 

_W 

D 

/ 

1 

1 

Dynamic 

15 + 3n 

' I 1 1 1 —I —1 - 1 — 1 —rn 

Depends upon D/I 





Immediate 

13 + 3n 1 


n = number of 
places shifted, or 
1 if none shifted. 


Time (cycles) 


A/L: 


t 


arithmetic 

logical 


(hex 8) 


D/I: 




Dynamic; 2nd word format: 

Immediate; 2nd word contains source value 


—1-1—1- 

0 

—1—1—1_ 

~I-1-1— 

src R 

—1_i__J 

• 1 1 

0 

—1_» « 

—1—1-1— 

0 

—1—1_1_ 


(hex 2) 
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Note: The source value for SR(^)(®) is specified as positive in assembly 
language, but a negative value is assembled into the instruction; con¬ 
sistency with usage for other instructions would have required: 

SA RO, # - 5 instead of SRA RO, #5 
SA RO, #5 instead of SLA RO, #5 

SA R0,R1 instead of SDA R0,R1 
Such usage would have been too inconvenient and error-prone. 
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42. TCC(B) cc, R 


C Z S V D H 


Test Condition Code 

If the combination of FLAGS bits encoded in the cc field is true, 
then the low order bit of the destination value is set to 1; otherwise 
the low order bit is unchanged (NB: not set to zero). 


AE -f W 

I I I i I 


dst R 


cc 


Time (cycles): 5 


Example: 1 1 | o | o [T] 

C Z S V 


RO = 0. 


TCC LE,R0 

!R0 = 0001,*; 

LE is true! 

TCC GT,R0 

!R0 = 0001,*; 

GT is false—but didn’t clear RO! 

CLR RO 

!R0 = 0! 


TCC GT,R0 

!R0 = 0! 
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43. TEST(®) dst 








C Z S P D H 

(See note) 


Test 

Set Z if destination value is zero, S if high order bit is set, P if TESTB 
and destination value has even parity. 


R @ DA X 

TEST(B) 

TESTL 


( OC + W: TEST(B); op2 = 4 
( 1C: TESTL; op2 = 8 

Note: P is unaffected for TEST, undefined for TESTL. 


—T” 

— 1 — 1-1 — 1-1— 

-1-1."T""— 

.1—1—1— 

mode 

op 

- 1 — 1 —i—i— 1 — 

dsf 

op2 

_ 1 - 1 — 1 — 


dst modes: 0,4,8 


7 

8 

11 

12 

13 

13 

16 

17 


Time (cycles) 


Example: ro = ffot. 

TESTRO ! I 0 I I I ! 

z s 


TESTB RHO ! o i i ! 
TESTB RLO ! ~~~ ! 

z s p 
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44. TR(T)(^)(R)B string @R, table @R, cnt R 


TRDB, TRDRB, TRIB, TRIRB, < I I I 1 I 

TRTDB, TRTDRB,TRTIB, TRTIRB 


Translate (Block) 

The byte addressed by the string register is used as an index to a 
table of bytes whose base address is in the table register. The byte so 
addressed is called a translation of the original byte; it is stored in one 
of two places, depending on (T). 

Then the contents of the cnt register are decremented by 1, and V is 
set if the resulting contents are zero. 

Options: 

(T): If T, then the translation is stored in the byte register 
RHl, and Z is set if the translation value is zero; if not T, 
the translation replaces the original byte addressed by 
the string register; then RHl and Z are undefined, 

(^): If D, autodecrement the string register; if I, autoincre¬ 
ment; the change is by ± 1. 

(R): If R, repeat the instruction until cnt is decremented to 0 
or (only for T) RHl gets a non-zero translated value. 


Time (cycles): 11 -}- 14n. 
n is the number of executions; n = 1 
if not R. 



1 = decrement 

D. 

i 1 = repeat ^ 


dst = RHl;7>srfor = 0 

K. 

0 = increment 

( 0 = do once 

\0: 

dst = ©string (do not test) 

(hex 8) 

(hex 4) 

(hex 2) 


—1—1—1—1—1—1—1— 

B8 

—1-1—1— 

string @R 

D 

I 

T 

0 

—1-1— 

0 

-1—1—1— 

cnt R 

_ \ _1_l_ 

1 1 1 

table @R 

_l_1_1 


( 

1_1 

) 
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Note: The assembly language designation ©table is misleading. The 
argument fetch uses table in a variation of base indexed addressing: 
table(@string). 


Example: Assume given a table in data memory that has 128 1-byte 
entries: for each i, 0 4i 4127, the /-th entry is the EBCDIC code for 
the character whose ASCII code is i (EBCDIC is another character 
code). The address of the table is ASCEBC. Assume an 80-character 
string of ASCII characters starting in data memory at CHARSTR. 


LD R3,ira0 
LDA R2,ASCEBC 
LDA Rl,CHARSTR 
TRIRB @R1,@R2,R3 


!Length of string! 

!Adr. of table! 

!Adr. of string! 

!String is converted to EBCDIC! 
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45. TSET(B) dst 




C Z S V D H 


Test and Set 

The sign of the destination value is tested and S is set accordingly; 
then the destination value is replaced by - 1. 


—1— 

—1-1—1—1—1— 

—1—1—1— 

—1—I—1— 


@ 

DA 

X 

mode 

_1_ 

oc + w 

_1_1_■ « « 

dst 

_i.i—J_ 

6 

_l_» » 


7 

11 

14 

M 


dst modes: 0,4,8 


Note: This instruction is intended for implementation of semaphores: 
control flags for shared resources. The intended convention is 

positive = free, 

negative = in use. 


BUSRQ is not honored during execution of this instruction, so if 
there is only one CPU in the system, there can be no other access to 
the semaphore between the test and the set. 

Example: 

WAIT: TSET SEMA !Wait for SEMA to become positive! 

JR MI,WAIT 
(use the resource) 

CLRSEMA !Release the resource! 

The shared resource in this example could be a set of program flags 
or data or it could be access to CPU control registers. 
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Chapter V 

Z8000 Addressing Modes 


In Chapter IV we described all of the Z8000 instructions, and we 
alluded to the addressing modes they use to express the location of 
their arguments. In this chapter we shall discuss those addressing 
modes. 

Instructions take their arguments from three places: from the in¬ 
struction itself, from a register, or from a memory location. If an 
instruction takes its argument from a memory location, the address 
can be found in one of three ways: in the instruction itself, in a 
register, or by a computation. The computations used for addresses all 
involve adding an address and an offset. There are three variations: 
the address and the offset can both be in registers, the address can be 
in a register and the offset in the instruction, the offset can be in a 
register and the address in the instruction. Figure 5.1 shows this tree of 
possibilities and the symbols associated with the corresponding 
address modes. 

Figure 5.1 does not distinguish between source and destination 
arguments, but the only time it makes a difference is when the argu¬ 
ment is in the instruction; this can only be a source argument. All of 
the other modes pictured can be for either source or destination argu¬ 
ments. 

It is not hard to see why we have immediate (#), register (R), direct 
address (DA) and indirect register (@) modes, but why B, X and BX? 
In early computers only the X mode existed. For example, on the IBM 
7094 one wrote the equivalent of 

LD R0,TABLE(R1) 
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5.1: The Z8000 Address Modes 

In that case, R1 was not a general purpose register; it was an index 
register. It had 15 bits, while the accumulators had 36 bits and the 
address fields of instructions (there were no address registers) had 18 
bits. The address TABLE was in the instruction. 

When later computers developed with many general purpose 
registers, a new use for indexing came about. If a general purpose 
register, R, can be a stack pointer and an index register, then the items 
on the stack can be addressed as 0(R), 2(R), 4(R), etc. (See the examples 
for Instruction Descriptions 35. POP and 36. PUSH.) This is using the 
indexing mode backwards, since 0, 2, 4, etc., should be addresses and 
R should contain an offset, but actually, R contains the address and 0, 
2, 4, etc., are offsets. If offsets and addresses are indistinguishable 
from one another, then this makes no difference, but on a segmented 
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T—r I I — T — I — I — I — I — I — I 1 1 —r— r 

Address 

i i * * * * * 1 * * « * * * * 

NON-SEGMENTED ADDRESS 
16 bits address 65,536 bytes 


0 

— 1 — 1 — 1 — 1 — 1 — 1 — 

Segment number 

- 1 1— I - 1-1-1-1- 

RESERVED 


r 1 I f 1 t t 

Address within S 

l 1 1 i_ L .-L. J_ 1 

legment (offset) 


LONG SEGMENTED ADDRESS 
23 bits address 8,388,608 bytes 
7-bit segment number addresses 128 segments 
16-bit offset addresses 65,536 bytes 


Segment Number 


Offset 


SHORT SEGMENTED ADDRESS 
15 bits address 32,768 bytes 
7-bit segment number addresses 128 segments 
8-bit offset addresses 256 bytes 


5.2: Address Formats Used in Instructions 


Z8000 this isn’t true. This is the reason for the based addressing mode 
(B); it makes 2(R) possible again, although for B it is written R(#2). 
This is in keeping with the original usage: base address outside the 
parentheses, offset inside. 

The base indexed mode (BX) is the next logical step; sometimes 
neither the base address nor the offset is known until execution time 
(e.g., see Figure 3.9). 

In Chapter II we discussed the register format of segmented addresses 
(see Figure 2.3). As Figure 5.1 shows there are two modes (DA and X) 
for which an address appears in the instruction, and there are three 
formats for that: one for non-segmented addresses and two for seg¬ 
mented addresses. Figure 5.2 shows these formats. 

This means that whenever the mode field controlling either src or 


ADDRESSING MODES 179 



5 


0 


-I—I-h 


-l-H—h 


■4—h 


4—1—h 


-i_l_L. 


Address of X 


CPLRR2,X(R6) (Non-Segmented) 


0 

t—f- 


“T—I—r- 

6 

+-4—h 

0 

♦ I > 


5 


2 

0 


Segment of X 

4- 


H-1—•—f- 


Address of X in Segment 

.JL—I_I_I-1-1-1- 


CPLRR2,X(R6) (Segmented, Long Address) 


— 1—\ —1— 

5 

1 1 • 

—1—1—r— 

0 

1 1 1 

1 j Segr 

__ 1 _ 1 _ 1 

nent of X 

1 _ 1 _ 1 _ 1 _ 


T - — r " ~T 

6 

4—1-h 


-T— 1 —r 

2 

4—1—h 


-L. 


Adr of X in Seg. 


CPL RR2,X(R6) (Segmented, Short Address) 


n—1—1— 

-1-1-1- 

—1—1— 1 — 


5 

0 

0 

IH 

» t 4 

♦ » ♦ ■ 

i i »-■ 



J_L. 


Address of X 

-J_I_I_I I .i-L. 


i 1. JL« .1, 


CPL RR2,X (Non-Segmented) 


-' -- * - ^ 

mode 1 

_L_l_I_L 


T 

0 

J- 


T—rn— 


src 


dst R 

I A . 


T 

J. 


CPL R,src 

(Basic Instruction Used Above) 


5.3: Addresses in Instructions 
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CPL RR2,#%6789ABCD 



-1-1-1-1-1— 

-1-1-1- 


mode 

1 0 

src 


1 

_ 1 _ till _ 

...i..A. 



CPL R,src 


(Basic instruction used above) 


' 1 1 

1 

t t 1 

—1 —1-1— 

B 

1 1 1 

—1—1—r— 

0 

1 1 i 

■M 

t t f 

0 

» > « 

Iff 

0 

_1_1_1_ 

t 1 f 

2 

_1_1_1_ 

UN 


DIV RR6,n6 


- 1 - 

- 1 - 1 

- 1 - 1 - 1— 

- 1 - 1 - 1 - 


mode 

1 

B 

src 


1 

_ 1 _ 1 

_ 1 _ 1 _ 1 _ 

1 1 1 



DIV R,src 

(Basic instruction used above) 


5.4: Examples of Immediate Arguments 

dst contains the value 4 (see Figure 4.16), an address in one of the 
three formats must follow the basic instruction in the program 
memory. Figure 5.3 shows examples of this. Notice how the 
instruction format constructed at assembly time must match the seg¬ 
mentation mode set at execution time. This does not happen (except 
the restriction to even-numbered registers) with the instruction formats 
for the other five address modes. 

Of the other three “ordinary” formats (R, #) only # requires 
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HI 

-1-1-1- 

0 

1 1 1 

HI 

HI 

1-1-1— 

0 

_1_1_1_ 

t 1 1 

0 

_1_1_1_ 

-1 »-1 

0 

_1_J_1_ 

HI 

LDBRH4,R6(<^^2) (Non-Segmented) 
LDBRH4,RR6(^2) (Segmented) 

HI 

1 1 1 

0 

1 1 1 

1 I 1 

Base R 

1 1 t 

1 1 1 

R 

-1-1-1— 

_1_1_1_ 

1 1 » 1 

oii 

_1_1_1_ 

II 1 

set 

L_1_ 1 _1_ 

1 I T '' 

_1_1_l_ 


LDB R, Base R(#offset) 
(Instruction format used above) 


HI 

-1-1-1- 

0 

_1_1_1_ 

HI 

HI 

-1—1-1— 

0 

_1_1_1_ 

HI 

-1-1-1- 

0 

_1_1_1_ 

-1—1-1— 

0 

_i__1_1_ 

LDB RL4,R6(R2) (Non-Segmented) 

LDB RL4,RR6(R2) (Segmented) 

HI 

1 1 1 

0 

_1_1_1_ 

I 1 1 

Base R 

1 1 1 

I 1 I 

R 

111 

1 1 1 

0 

_1_« « 


1 1 1 

0 

_1_1_ i _ 

1 1 1 

0 

_1_1_i_ 


LDB R, Base R (offset R) 

(Instruction format used above) 

5.5: Examples of Based and Base Indexed Modes 


additional memory beyond the basic instruction; whenever the com¬ 
bination of a zero mode with RO in the controlled src field appears (see 
Figure 4.16), the source value is appended to the basic instruction. 
Figure 5.4 gives examples of this. In the few cases in which an instruction 
contains both an address and immediate data, the address always 
appears first. 

The other two address modes, B and BX are only available with the 
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HEX 

MEANINGS 

HEX 

MEANINGS 

0 

R0,RH0,RR0,RQ0 

8 

R8,RL0,RR8,RQ8 

1 

Rl^RHl 

9 

R9,RL1 

2 

R2,RH2,RR2 

A 

R10,RL2,RR10 

3 

R3,RH3 

B 

R11,RL3 

4 

R4,RH4,RR4,RQ4 

C 

R12,RL4,RR12,RQ12 

5 

R5,RH5 

D 

R13,RL5 

6 

R6,RH6,RR6 

E 

R14,RL6,RR14 

7 

R7,RH7 

F 

R15,RL7 


5.6: Interpretation of Register Fields in Instructions 


LD and LDA instructions. The complete formats, including the offset 
in the instruction for B, are shown in the corresponding instruction 
descriptions. Figure 5.5 shows some examples. Notice that the same 
instruction has two different meanings, depending on whether the 
CPU is running in segmented or non-segmented mode. 

There is another point that is important if you wish to use separate 
data and stack spaces: the CPU status outputs take the “stack refer¬ 
ence” value whenever the stack register (R15 or RR14) is used as an 
address register, i.e., in the @ and B modes and when it is the base 
in BX mode. When it is used as an index (e.g., 2(SR)), the status lines 
show a data memory reference. 

Also note the hexadecimal encoding of the byte registers: RHO to 
RH7 are numbered 0 to 7; RLO to RL7 are 8 to F. Figure 5.6 shows all 
of the register encodings used in instructions. Except for RLO, . . . , 
RL7, each is encoded by its number in the assembly language 
designation. That is, Rn, RRn, RQn, and RHn all appear as n in a 
register field; RLn appears as 8 + n. 

There is one more address mode available, designed for references 
to program address space: relative addressing. The relative address 
mode derives an address by addition to or subtraction from the PC of 
an offset contained in the instruction. There are several variations on 
this, which are all described in the various instruction descriptions 
(CALR, JR, LDAR, LDR). Specification of this mode is built into 
the assembler mnemonic. One point to remember is that the PC 
value used in relative addressing is the one for the location following 
the instruction. The various instruction descriptions relate this to “$,” 
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the location counter. That is, in the instruction descriptions the rela¬ 
tive addressing “window” is stated in terms of the address of the in¬ 
struction. But if you are assembling one of these instructions by hand, 
you must remember to compute the offset from the address of the 
following instruction. 

This concludes our description of the ZSOOO instructions and 
addressing modes. The remainder of the book explains how to use 
them. 
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Chapter VI 

Input/Output Techniques 


The Z8000 CPU is a 40 or 48 pin chip; all of its communication with 
external devices must be through those pins. All I/O depends on the 
zeroes and ones on the address/data pins (ADis - ADo), feee ^s 
comrol pins (AS, MREQ, DS), the seven st atus pins ( R/W, B/W, 
N/S, ST 3 - STo) and the three interrupt pins (NMI, NVI, VI). 

Of course, all of the internal CPU operations depend on zeroes and 
ones in various registers and on various busses, but CPU development 
over the years has led us further and further from the basic ones and 
zeroes by supporting operations at higher and higher levels of ab¬ 
straction. In the same way, each new generation of microprocessors is 
able to deal with I/O at higher and higher levels than delays and pulses 
on individual lines. However, these developments have come largely in 
the form of optional external support chips. This means that they can 
be omitted when cost and component count are prime considerations. 
And even when they are included, the fact that they are external com¬ 
ponents means that the programmer has more of the responsibility for 
I/O details than would otherwise be the case. 

For these reasons we discuss in this chapter some of the traditional 
microprocessor I/O techniques such as delays, pulses, processing 
serial bit streams, controlling timing and the like. In the next chapter 
we shall discuss the special components that make these techniques 
obsolete. 

The sixteen address/data pins of the Z8000 CPU are made 
available to I/O devices by means of a bus. As its derivation from the 
Latin word omnibus indicates, the bus is for every device to use. Like 
a transit route, it connects all of the devices in the system, and signals 
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can get on at any of these connections. The I/O bus also includes the 
three bus control and seven status lines mentioned above. These bus 
control and status lines are not directly under the programmer’s 
control; the Z8000 CPU puts signals on them as appropriate. 

The programmer controls the address/data lines with the I/O 
instructions (see Descriptions 19 and 20). For example, the command 

INB RL0,%1E 

causes the Z8000 CPU to conduct the necessary bus protocol to obtain 
one byte of data from the I/O device that responds to address lEi 6 . 
Theactual sequence of signals on AD 15 - ADo, MREQ, AS, DS, B/W, 
R/W and ST 3 -ST 0 need not concern us here. All we need to know 
is that the device we are interested in will send us a byte of data if we 
address it as IEi 6 . 

There are several points worth noting about I/O addresses like IE 
above: the y are an entirely separate address space from the memory 
addresses (MREQ is used to distinguish a memory request from an 
I/O request); and they can range from 0 to FFFF (64K), but they don’t 
need to. For example, the device that responds to IE may also respond 
to 5E, DE, FFIE, etc., if it is only looking at the low order 6 bits of 
ADis-ADo, i.e., at AD 5 - AD 0 . 

Let’s take the simplest possible I/O example: a switch. Assume that 
when bit zero of I/O address FURN is set to one, it causes a switch to 
be turned on, and a zero turns it off. To make it interesting, imagine 
that the switch controls your furnace. Therefore, 

LDB RH0,#1 
OUTB FURN,RH0 

will turn on your furnace; 

CLRB RHO 
OUTB FURN,RH0 

will turn if off. The signal generated by either of these instruction 
pairs is called a level. The signal generated by one followed by the 
other is called a pulse. The time between the two is the duration of the 
pulse. For example, you might use the sequence 


186 PROGRAMMING THE Z8000 



LDB RH0,#1 
OUTB FURN, RHO 
(wait 20 minutes) 
CLRB RHO 
OUTB FURN,RHO 


to give your furnace a pulse of duration 20 minutes. The “wait 20 
minutes” section could be provided by 

LDL RRO,#-240000000 
X: ADDL RR0,#1 

JR NZ,X 


EXERCISE 1: (a) Verify that the above loop waits 20 minutes if the clock 
is running at 4MHz. 

(b) How long a pulse is generated by the sequence 


LDK R0,#l;OUTB RL0,FURN; OUTB RHO,FURN 


(c) Give a sequence that generates a pulse of 20/i s. 

In the preceding example the only criterion we had to meet was that 
the pulse be of twenty minutes’ duration. A harder problem to solve is 
putting delays and instructions together so that an overall time 
interval, as well as its subintervals, is of precisely measured duration. 
For example, if our furnace had to come on for twenty minutes once 
every hour on the hour, then we should have to follow our twenty 
minute pulse with a forty minute delay until the next pulse. The on and 
off instructions take so little time compared to the hour time scale that 
they don’t affect things, but if it took a minute to turn on the furnace 
and a minute to turn it off, then the entire process would take sixty- 
two minutes, and at the end of a day the furnace would be coming on 
forty-eight minutes late. 

Of course, we could shrink our forty-minute delay to thirty-eight 
minutes and the problem would go away. But suppose that every third 
hour it took an extra thirty seconds to turn on the furnace and that 
every twelfth hour a fifteen minute examination had to be conducted 
with results monitored by the computer. 

Naturally, it doesn’t matter whether or not your furnace comes on 
exactly on the hour, but there are many computer applications where 
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precise timing does matter. For example, synchronous bit serial data 
transmission. 

Synchronous Bit Serial Data Transmission 

Imagine a device that transmits 8-bit ASCII characters to the com¬ 
puter at a rate of 125 characters (1000 bits) per second. Assume that it 
does so by setting a register to one or zero for one millisecond for each 
bit of each character. Also assume that, when the Z8000 CPU executes 
an INB RL0,DEVICE the value in the register is read into bit zero of 
RLO. Then all the computer has to do is start reading the register at 
one millisecond intervals. The bits must be accumulated into bytes, 
and each time a byte is formed it must be stored somewhere. Just to be 
on the safe side, assume that we start reading half way through the one 
millisecond interval for the first bit; then reading at one millisecond 
intervals will put us in the middle of each bit with room for 500 /xs 
leeway on either side. But if our one millisecond timing is only off by 
250 nanoseconds (one clock cycle), then in 250 characters (2 seconds), 
we shall have drifted from the center of the bit range to the edge; we 
shall be out of sync. 

EXERCISE 2: (a) Write a segment of code that delays for exactly 4000 
clock cycles. 

(b) Can you always write code to delay any given number of clock cycles? 

(c) What about times (e.g,, one-third second) that aren’t a whole 
number of clock cycles? 

The problems shown by the previous example are easily solved by 
wasting bits now and then for resynchronization. If it is known, for 
example, that a certain bit will be set to one and that the following bit 
will be zero, then all we have to do is start a loop 

X: INB RL0,DEVICE; TESTB RLO; JR NZ,X 

somewhere during the time for the known one bit. When it stops looping 
we shall be at the start of the known zero bit; then a delay of one half 
bit time (500 ms in this case) will resynchronize us at the middle of the 
bit time for the known zero bit. 

Most devices transmitting ASCII under the EIA RS-232 protocol 
use a scheme like this on a character-by-character basis: each 
character has a start bit and one or two stop bits. Usually, the stop bit 
has the same value the device transmits when it isn’t sending characters. 
The start bit has the opposite value. That means that the stop bits are 
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ones and the start bit is zero, since a non-transmitting device will 
usually be sending a one to let you know it is still there. 

The most popular computer terminal of the 1960’s (and still widely 
used) is the teletype. It uses a protocol called “20 milliamp current 
loop.” It transmits a start bit and two stop bits, and its character rate 
is ten per second. Figure 6.1 gives an algorithm for reading teletype 
characters. Figure 6.2 shows a program to implement it. The 
subroutines DELHALF to delay one half bit time and DELBIT to 
delay a full bit time are not shown. TTYIN is assumed to be the 
symbolic name of the teletype input I/O address. 

EXERCISES: 

(a) Show that the bit time for a teletype is approximately 9.091 milli¬ 
seconds. 

(b) Write a routine DELHALF that delays 4.55 milliseconds. 

(c) Write DELBIT to consist of two consecutive calls to DELHALF. 

(d) What effect do these approximations and the failure to count the 
other instructions of INCH have on timing? At what point in the 9.091 
millisecond period is the eighth bit value read into the Z8000? If the 
program did not resync on each character, how soon would it be out of 
sync? 

(e) Explain RRCB RLO; RLCB RHO and “done if #1 comes out other 
end.” 


One thing that INCH does not do is “echo” characters back to the 
teletype. This can be achieved by the insertion of an 

OUTB TTYOUT.RLO 

immediately after the INB RLO, TTYIN (where TTYOUT is the symbolic 
name of the teletype output I/O address). There are two different 
modes of operation of terminal devices: full duplex and half duplex. 
In the half duplex mode the character corresponding to the key pressed 
by the operator is automatically typed by the terminal hardware simul¬ 
taneously with transmission (if any) to the computer. In the full duplex 
mode the computer is responsible for “echoing” back the received 
character. In full duplex operation the echoing can be simply an im¬ 
mediate response of the exact character typed, or the echoing can be 
handled by an entirely different program and may consist of a character 
or characters different from the character received. For example, 
when the operator presses RUBOUT at a CRT keyboard, the program 
may echo back the three character sequence BACKSPACE, SPACE, 
BACKSPACE (do you see why?). Or when the user presses RETURN, 
the sequence RETURN, LINEFEED might be echoed. 
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1. V\fait for the line to drop (indicating beginning of "start" bit). 
Initialize accumulating character. 

2 . Wait until middle of the start bit. 

3. Wait until middle of next bit. 

4. Read the bit value. 

5. Shift the bit into an accumulating character. 

6 . If the entire character is not yet accumulated, go back to 
step 3. 

7. Store the character. 

8 . If the character was a terminator, stop. 

9. Wait until the middle of the next ("stop") bit. 

10. Go back to step 1. 


6.1: Algorithm to Rood TTY Characters 

A routine like INCH would normally be used in a half duplex situa¬ 
tion or with an immediate mechanical echo. A higher level program 
would become involved in echoing where a parallel interface was used. 
With INCH, all of the computer’s time is devoted to controlling the 
teletype transmission timing. 

Before we pass on, there is another point about Figure 6.2: notice 
that several lines have two instructions separated by a semicolon. If 
your assembler supports this feature, then you have to decide whether 
or not to use it. Being a matter of taste, this question has long been 
hotly argued. Those who use it say it provides an important way to 
group together instructions to clarify the program; those who dislike it 
say that departure from fixed instruction and comment columns 
makes a program look messy and hard to read. 

In the next chapter we shall discuss external devices that relieve the 
CPU of the need to concentrate its full attention on controlling timing 
for synchronous bit serial transmission. 


Parallel Asynchronous Data Transmission 

In synchronous transmission, sender and receiver “synchronize 
their watches’’ like spies or bank robbers; each does its part at the 
previously agreed to times and relies on the other to do likewise. Asyn¬ 
chronous transmission, on the other hand, relies on flags. 

On a rural delivery postal route, each patron keeps a little red flag in 
the mailbox. If the patron has mail to send out, it is placed in the box 
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!Subroutine to accept a string of TTY characters. 

CALL INLINE; R1 = address of buffer; 



RH2 = termination character. 

Read and store characters in the buffer addressed by R1 until and including the 
termination character in RH2. No characters are echoed. R1 is left pointing past 

the last char stored; RO is lost! 


INLINE: 

CALRINCH 

!Get one character! 


LDB @R1,RH0; INC R1 

!Store it! 


CPB RH0,RH2; RET EQ 

JR INLINE 

!Exit if terminator! 

INCH: 

INB RLO,TTYIN; TESTB RLO 

!Wait for line to drop! 


JR Z,INCH 

LDB RH0,#1 

!Initialize char accumulator! 


CALR DELHALF 

!Wait for center of start bit! 

LP: 

CALR DELBIT 

!Delay one bit time! 


INB RLO,TTYIN 

!Read value! 


RRCB RLO; RLCB RHO 

!Move bit into accumulator! 


JR NC,LP 

!Done if #1 comes out other end! 


CALR DELBIT 

!Get into first stop bit! 


RET 



6.2: Subroutine to Read TTY Characters 

and the flag is displayed outside the box. The mail carrier stops at any 
box that has a flag up, removes the outgoing mail and replaces the flag 
in the box. Thus, transmission of mail from postal patrons to the 
Postal Service follows an asynchronous protocol. 

Flags in the Z8000, like everything else, must be implemented using 
the address/data bus. For example, in the INCH program of Figure 
6.2, the INB RL0,TTYIN instruction is preceded by CALR DELBIT. 
Instead of a time delay DELBIT could consist of a wait for a flag: 

DELBIT: INB RLO,TINSTAT; TESTB RLO; JR PL,DELBIT; RET 

This routine waits for bit 7 of the status read from the symbolic I/O 
address TINSTAT to be set. The device, in responding to the 
INB RL0,TTYIN instruction, would then clear the bit 7 status flag 
and wouldn’t set it again until the next bit was ready. 

In fact, this sort of flag protocol, which is also called handshaking. 
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!Parallel version of INCH! 

INCH: CALR WAIT ! Wait for TTY flag! 

INB RLO, TTYIN 
RET 

WAIT: INB RLO,TINSTAT; TESTB RLO; JR PL,WAIT; RET 


6.3: Parallel Version of INCH 

is not often used with bit serial transmission. However, it is the principal 
protocol used with parallel transmission: transmission in which several 
bits are transmitted simultaneously. A parallel interface for a teletype 
typically sends an 8-bit ASCII character each time the INB RLO,TTYIN 
is executed. A wait-for-flag routine, like the one above, would wait 
until an entire character is ready. Figure 6.3 shows a parallel version 
of INCH. 

Asynchronous parallel output is similar to input. Figure 6.4 shows a 
character output routine analogous to INCH. One interesting point 
has to do with “priming” the device. It is possible, under certain 
conditions with certain interface designs, that the ready status in 
TOUTSTAT won’t be set the first time the routine is called, so 
that the WAITOUT program will never return. Since we are as¬ 
suming (as is always the case) that the OUTB TTYOUT,RLO will 
cause the flag to be set, one solution is to interchange the order of 
the OUTB TTYOUT,RLO and the CALR WAITOUT, but this forces a 
wait of one-tenth second (for an unbuffered teletype), while doing it in 


!TTY Character Output Routine 

CALLOUTCH; RLO = Char to output! 

OUTCH: PUSH @SR,R0 

!Save RO! 

CALR WAITOUT 

!Wait until TTY is ready to receive! 

OUTB TTYOUT,RLO 

!Output the character! 

POP R0,@SR 

!Restore RO! 

RET 

WAITOUT: INB RHO,TOUTSTAT; 

TESTB RHO; JR PL,WAITOUT; RET 


6.4: Output Equivalent of INCH 
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the other order lets all necessary processing be done first and cuts the 
wait time down to the minimum necessary. Another possible solution 
(the usual one) is to have an initialization routine send a null character 
to the TTY (or other such device) when the system starts up. Later in 
this chapter we shall find an even better solution when interrupts are 
used. 


Transmission Bandwith 


An interesting measure of the power of a computer is its maximum 
transmission rate, also called bandwidth. Figure 6.5 shows two high¬ 
speed input routines. One tests status, the other assumes that the 
device is always ready and uses a block I/O instruction with the repeat 
option. Each is analyzed for maximum transfer speed (assuming that 
the device is always ready). This analysis shows that a status-testing 
routine can support data rates over 80K bytes/sec; the block I/O 


!Subroutines to transfer a block of data into memory 


CALL FASTIN; 


RO = n (number of characters to input) 
R1 = address of buffer 
R2 = I/O address to input from 
R3 = status I/O address 


CALL FASTER; R0,R1 ,R2 as above 

R3 not used 

I 

FASTIN: INB RL4,@R3; TESTB RL4 

JR PL,FASTIN 
INIB@R1,@R2,R0 
JR NOV,FASTIN 
RET 


!Wait at least 23 cycles! 
IGet & store byte: 21 cycles! 
!V means “done”: 6 cycles! 
! TOTAL 50n ! 


FASTER: INIRB @R1,@R2,R0 !TOTAL 11 + lOn cycles! 

RET 

!Assuming that n = 256 (it only matters for FASTER), transfer rates with cycle 
time of 250 nanoseconds are: 


FASTIN: (50x250x 10-’)“' = 80,000 bytes/second 

FASTER: ((10 + ll/n)x250x lO"’)"' = 398,289 bytes/second 


f 


6.5: Z8000 Parallel Transfer Rates 
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instruction can achieve 398K bytes/sec. Devices that transmit 16 bits at 
once could achieve twice this transfer rate. 

EXERCISE 4: Carry out the analysis of Figure 6.5 and verify the transfer 
rates given. Perform a similar analysis for memory-to-memory transfers, 
using ordinary and block load instructions. 


Seven-Segment Display Example 

Many microcomputer systems are equipped with a seven-segment 
display device such as an LED. Figure 6.6 illustrates the use of this 
seven-segment code. 


EXERCISE 5: (a) Verify the table in Figure 6.6. 

(b) Seven-segment code encodes exactly as many characters as ASCII. 
Could this be useful? Refer to Figure 1.15 and draw the seven-segment 
pictures that would result from the ASCII codes for 0, 1, 2, . . . What 
ASCII characters do the codes of Figure 6.6 correspond to? 


Figure 6.7 shows a program to cycle through a string of hex digits 
and output them to LED’s. It cycles through the LED’s continually, 
turning each one on for a little while. By cycling quickly enough the 
program can keep them all lit without flickering. The constant k 
determines how long the program will stay at each LED. If k is too 
small, the LED’s won’t appear lit at all; if it is too large, the others 
will appear to go out as each one is being lit. 

EXERCISE 6: Assume that a value of k =50 is the minimum that will 
make an LED visible and that higher values of k are better. Assume also 
that the loop at X must be executed at least once every 100 milliseconds 
for each LED. What is the maximum possible value for n? What is the 
relation between n and k? Of course, actual values will depend upon the 
LED specs. 

There are several other things worth noting about the program of 
Figure 6.7. First notice the “! ” directly above the first instruction line. 
Since the !’s bracket the commentary at the beginning of the program, 
lining them up like this is an aid to seeing clearly what they are bracketing 
and to assuring that they aren’t left out. This is a matter of style. 

Another point about this “subroutine” is that it never returns. 
Since the computer normally has other things to do, this could be 
remedied by changing the JR GE,DISLED in the last line to 

RET GE 
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The seven segments and their names 


f |_9_| b 

eLN 

d 

a a 

f( |b |b _^|b 

h ® L 

d d 

0 1 2 

Representation of some digits in seven-segment code 



0 

g 

f 

e 

d 

c 

b 

□ 


Binary encoding of any combination 
of segments in one byte 


Digit 

Code 

Digit 

Code 

Digit 

Code 

Digit 

Code 

0 

3F 

4 

66 

8 

7F 

C 

39 

1 

6 

5 

6D 

9 

67 

D 

5E 

2 

5B 

6 

7D 

A 

77 

E 

79 

3 

4F 

7 

7 

B 

7C 

F 

71 


Seven-segment encodings of all hex digits 


6.6: Seven-Segment Code 


Then the calling program would execute a sequence like: 

DISP: CALL DISLED !One pass over the LED’s! 
(do something else) 

JR DISP 
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!LED Display Program (non-segmented) 


CALL DISLED; RO = n (number of LED’s) 

R1 = adr of n hex digits, one/byte 

R2 = I/O adr of first LED (others are at following addresses) 
Internal register use: 


RL3 = Current 7-segment code to output 

R4 = LED counter (value cycles through 0,1,... ,n- 1 , 0 , 1 ,_) 

R5 = I/O address pointer (always contains R2 -t- R4) 

R6 = Hex value of current digit (from string addressed by Rl) 

R7 = Repeat counter for “burning in’’ LED 


f 


DISLED: 

LOOP: 


LIGHT: 


TABLE: 


CLR R4; LD R5,R2 
CLRB RH6 
LDB RL6,R1(R4) 

LDB RL3,TABLE(R6) 

LD R7,#k 

OUTB @R5,RL3 

DEC R7; JR GT,LIGHT 

INC R4; INC R5 

CP R4,R0; JR GL,DISLED 

JR LOOP 

(16 bytes corresponding to Figure 6.6) 


Unitialize counter, I/O ptr! 
lOnly low byte of R6 changes! 
INext hex digit! 

!7-seg code for next digit! 

!Burn-in counter! 

!Light the digit! 

!Make sure it shows! 

!Next digit, next LED! 

!Ifctr >n then DISLED! 

! else LOOP! 


6.7: LED Display Program 

The time spent in the “do something else” phase would have to be 
small enough to assure a flicker-free display. 

The TABLE at the bottom of Figure 6.7 reveals several issues. Since 
it is addressed by the instruction 

LDB RL3,TABLE(k6) 

it must be in data memory. Naturally, this hex-to-seven-segment 
conversion table is part of the program; you would want it to reside in 
ROM with your program if you were setting things up that way. So in 
a situation like this, it is easiest not to have separate program and data 
address spaces. The way you actually fill in the values for TABLE also 
depends on your assembler; ideally it will allow something like: 
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TABLE: HEXBYTES (3F, 6, 5B, 4F, 66, 6D, 7D, 7, 7F, 

67,77,7C, 39, 5E,79,71) 

It is possible that you will have to do something like: 

TABLE: bval %3F; bval %6; bval ®7o5B; etc. 

I/O Scheduling 

There are two main ways to schedule data transmissions to and 
from the computer: polling and interrupts. 

The mail carrier who makes a daily round looking for flags on 
mailboxes is conducting a polling scheme. A postal clerk who suspends 
regular duties each time a letter is dropped through the mail slot in the 
post office lobby and then resumes the duties after processing the 
letter is using interrupts to schedule transmission. 

In the computer, polling consists of repeated executions of a sequence 
such as the one shown in Figure 6.8. Each device’s status is checked 
with code like 

FASTIN: INB RL4,@R3; TESTB RL4; JR PL,FASTIN 

from Figure 6.5, but instead of the JR PL,FASTIN, which waits until 
the device is ready, the polling sequence will have a jump to the next 
test—jumping around the call to the device service routine. 

If the microprocessor has anything else to do besides servicing de¬ 
vices, then that activity has to be integrated with the polling loop. For 
example, a subroutine call might appear just before the 

“Go back to LOOP” 

in Figure 6.8. If there is any urgency or timing constraint (e.g., LED’s 
need to be serviced every one-tenth second), then polling becomes 
more complicated. One approach is for the CPU to take account of 
priorities', a simple way would be to arrange the device checks of 
Figure 6.8 in order of importance. Then after each call to a device 
service routine the program could transfer back to LOOP instead of 
going on to the next test. 

Figure 6.8 represents what is called a round robin’, the transfer back 
to LOOP after each device service routine call transforms it into a 
fixed priority scheme. The biggest problem with the fixed priority 
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LOOP: If Device 1 needs service, call the Device 1 service routine 
If Device 2 needs service, call the Device 2 service routine 


If Device N needs service, call the Device N service routine 
Go back to LOOP 


6*8: Typical Polling Sequence 


scheme is that priorities are not fixed. A low-priority device that has 
not been serviced in a while may become, briefly, a high-priority 
device. A solution to this would be to vary priorities according to the 
situation. Sophisticated work has been done in this area, but for 
ordinary systems the benefit is probably not worth the effort. In most 
cases a round robin is best, using carefully written service routines that 
run for as short a time as possible each time they are called. 

If the computer has much to do besides servicing devices, then 
polling quickly becomes unworkable. Fortunately, the ZSOOO provides 
good support for scheduling with interrupts. In Chapter II we discussed 
the program status area (PSA) and the saving and restoring of CPU 
status when interrupts occur. In Chapter IX we shall show how to set 
up the PSA. For the discussion that follows we only need to know that 
the CPU provides some means of transferring to an appropriate 
service routine when an interrupt occurs. 

Device service routines are essentially the same, regardless of 
whether they are scheduled with polling or with interrupts. In fact, the 
simplest kind of interrupt facility (the NVI in the ZSOOO) is handled by 
a sequence exactly like that in Figure 6.8. The difference is that with 
interrupts the program only arrives at LOOP when some device has 
signaled that it needs service. A complete pass can be made through 
the loop and an IRET executed at the end, or each device service 
routine can contain an IRET. In the latter case, another interrupt will 
occur if another device needs service, and the program will come to 
LOOP again. 

The overhead of the loop of Figure 6.8 is eliminated altogether by 
the vectored interrupt. Each device connected to the VI must supply 
an identifier to the CPU. The CPU has the ability to find a memory 
location containing that device’s service routine address and to 
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transfer directly to the service routine. A memory location dedicated 
to holding a service routine address to be used in this way is called an 
interrupt vector (from the Latin word for arrow). A service routine 
reached in this fashion must end with an IRET, since that is the only 
kind of return it can make. 

Device service routines can be very simple or they can be complex, 
especially if the device can be involved in more than one kind of acti¬ 
vity. The complexity can arise from the fact that they have to re¬ 
construct their context each time they are called; that is, they need to 
know what they were doing and how far along in it they were. 

An Example 

It is difficult to get a good feeling for this type of programming 
without an extensive example, so the remainder of this chapter will be 
devoted to presenting the device service routines necessary to handle a 
terminal (i.e., CRT, Teletype, etc.) 

A terminal consists of two devices: a keyboard and a “printer.” 
The keyboard service routine is fairly simple, since all it has to do is 
accept characters. The printer service routine is more complicated, 
since it can be used either to output messages to the operator or to 
echo back the characters accepted by the keyboard routine. Echoing is 
further complicated by the fact that some keyboard characters can 
generate output strings more than one character long (e.g., RUBOUT 
can generate “BACKSPACE, SPACE, BACKSPACE” for a CRT 
screen to wipe out the previous character and reposition the cursor 
where the wiped out character was); when the service routine finishes 
printing a string it needs to know whether it has finished or whether it 
should return to echoing. 

Figure 6.9 shows an algorithm for the terminal output service 
routine—the routine that actually sends characters to the TTY or CRT 
screen whenever the device interrupts to say that it is ready for 
another. It is presented in “pseudocode”; this is an alternative form 
of algorithm presentation that makes use of the control structures 
found in higher level languages. This can be much clearer than the 
other*form we discussed for algorithms in a case like this one in which 
there is a great amount of jumping around. 

The idea behind pseudocode is that you try to express the algorithm 
clearly, mixing verbal descriptions with instructions or control 
structures in a casual approximation of some programming language 
that is familiar to you and likely to be understood by whoever has to 
read it. 
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Terminal Output Service Routine: 

If Case FLAG = ''input" then go to Echoing 
Case FLAG = "echostring" then go to String Echoing 
Case FLAG = "output" then go to Printing 
Else go to Error IShould not enter routine if "done" or "sleep"! 

Echoing: Get next character from input buffer 
If none in buffer, set FLAG = "sleep" and IRET 
Else if Case character = RUBOUT or BS, then to to Rubbing 
Case character = ESC, then go to ESCing 
Case character = CR, then go to Terminating 
Else go to Character Printing Ilf nothing special, just echo it! 
Rubbing: Remove last character of LINE 
If none in Line, then go to Echoing 

Else (remove last character added to LINE; set PTR to "BS, 
SPACE,BS"; set FLAG = "echostring"; go to String Echoing) 
ESCing: Add ESC to LINE; set PTR to "$/" 

set FLAG = "echostring"; go to String Echoing 
Terminating: Add NUL to LINE; set PTR to "CR, LF" 
set FLAG = "output"; go to Printing 
Character Printing: Add character to LINE; output character; IRET 

String Echoing: If PTR points at "NUL", then (set FLAG = "input"; 
go to Echoing) 

Else (output char pointed to by PTR; INC PTR; IRET) 

Printing: If PTR points at "NUL", then (set FLAG = "done"; IRET) 
Else (output char pointed to by PTR; INC PTR; IRET) 

Error: (To be specified.) 


6.9: Pseudocode for Terminal Output Service Routine 

EXERCISE 7: Try to write the algorithm of Figure 6.9 in the earlier algo¬ 
rithm format. Don’t bother to finish; just go far enough to convince 
yourself that the resulting product would be extremely difficult to 
understand. 

The terminal output service routine is just one piece of a system of 
programs. In Chapter VIII we shall present an initiating program that is 
called whenever the programmer needs to output to the printer/ 
screen or input from the keyboard. The initiating program waits until 
the previous task is completed, then it sets the proper values into the 
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controlling variables FLAG and PTR and initializes LINE. (Look 
ahead to Figure 8.1.) 

As will be seen as we go through the algorithm of Figure 6.9, FLAG 
is what tells the service routine what it has been doing, PTR points at 
the next character to be output and LINE accumulates the input line 
being typed by the operator. These and the I/O addresses and input 
buffer to be used form the context in which the terminal output and 
input service routines operate. The initiating program’s job is to 
initialize the context for the input and output service routines. 

Finally, the initiating routine must get the entire process started, 
since the “ready” interrupt from the printer/screen will already have 
occurred; the hardware will have acknowledged it, so it will not occur 
again until another character is output. The initiating routine will 
simulate the interrupt by an SC function. Details will be discussed in 
Chapter IX. 

With this general idea of what the initiating routine will be doing, 
let us go through the terminal output service routine of Figure 6.9. 
Along the way we shall discover what the input routine has to do. 
After we have coded the output and input routines, we shall write the 
actual initiating routine. This will appear in Chapter VIII. 

First, the routine has to figure out what it has been doing. It looks 
at FLAG for this. FLAG can take five values: input, echostring, 
output, sleep and done. These have the following meanings: 

input: An input line is being built; the next character from the input 
buffer should be processed. 

echostring: The last processed input character required a special 
string of characters to be echoed; the next one from that string 
should be output. 

output: A string of text is being output to the printer/screen; the 
next character from that string should be output. 

sleep: At the last interrupt, FLAG had the value “input,” but there 
were no characters in the input buffer. The next time a character 
is input, the input routine should set FLAG back to “input and 
transfer into this routine. 

done: At the last interrupt, FLAG had the value “output” but PTR 
was pointing at the termination character of the output string; 
nothing should happen until the initiating routine starts some¬ 
thing else. 

Once the program has decided what it is doing it goes to the ap¬ 
propriate section of code. The sections String Echoing for FLAG = 
“echostring” and Printing for FLAG = “output” are simple and 
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very similar to one another; each puts out the next character and in¬ 
crements PTR. They differ in what they do at the end of the string: 
Printing sets FLAG = “done”; String Echoing sets it back to “input” 
and goes to get the next input character. Echoing is the complicated 
section. It gets the next character from the input buffer and processes 
it in one of four ways depending upon what character it is. If the input 
buffer is empty, FLAG is set to “sleep” as described above. 

Character Printing is the ordinary case: if there is nothing special 
about the character, it is echoed back to the operator and accumulated 
in the input line buffer LINE. 

Terminating is done when the operator presses RETURN: LINE is 
terminated so the programmer who called the initiating routine will 
know the extent of what was typed; the RETURN, LINEFEED 
sequence is echoed to bring the carriage/cursor to the leftmost posi¬ 
tion of the next line; FLAG is set to “output” since the input is done. 

Rubbing is what happens when the operator presses RUBOUT or 
BACKSPACE: the last previous character (if any) is removed from 
LINE; that character is blanked from the screen by the sequence 
BACKSPACE, SPACE, BACKSPACE; then input resumes. 

ESCing is here as an example—a prototype of the many special 
characters you might want to handle in special ways. Notice that the 
ESC itself is added to LINE, but the two characters “$/” are echoed 
back at the operator. 

EXERCISE 8: (a) There is a “bug” in connection with ESC; the sequence 
ESC, RUBOUT does the correct thing to LINE but leaves “$” on the 
screen. Can you think of a solution? 

(b) What other characters need special handling, and what problems do 
they pose? How about TAB, LINEFEED, or “control” characters? 


Figure 6.10 shows the terminal input service. routine in the same 
pseudocode form as we used for the output routine. Now we can write 
the actual code for these routines, but first we need to deal with the 
details of context switching. 

We said that the initiating routine initializes the context for the 
service routines, and we have indicated in the pseudocode versions 
that the service routines need access to this context. We make all this 
happen with a block of memory beginning at the symbolic address 
CONBLK; this block contains all of the items of the context for the 
service routines. When the service routines are invoked, registers will 
be saved on the stack and the context block read into the registers. 
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Terminal Input Service Routine: 

Get character from the Keyboard. 

Put it into the input buffer. 

If FLAG = "sleep" then go to Echoing else I RET 


6.10: Pseudocode for Terminal Input Service Routine 

When they finish, this will be undone just before the IRET. Figure 
6.11 shows the code for two routines to handle this: TYENT and 
TYEXIT. Each of the service routines begins with a call to TYENT to 
set up the context and ends with a call to TYEXIT to restore the registers 
prior to the IRET. 

Several items in Figure 6.11 need to be discussed. First notice the 
symbol definitions (e.g., TYCON = R2, FLAG = RH2). Their 
form will depend upon the particular Z8000 assembler used, but any 
assembler should be able to provide at least this much symbol defini¬ 
tion capability. Perhaps your assembler will allow other features that 
will make future changes easier and less error-prone. Constructions like 

PTR = TYCON -F 1 

RING = TYCON -F 2 


or even 


NTYCX = TYRT - TYCON + 1 

make it impossible to change one of a pair of related symbols without 
changing the other. 

One reason for taking care with these definitions is that they are to 
be used not just in TYENT and TYEXIT but also in our service routines 
TYOUT and TYIN and in the initiator routine TYIO. 

One essential point about Figure 6.11 is that mueh of the context 
consists of addresses', as shown here these programs work only for the 
non-segmented Z8000. The segmented versions are analogous but 
different. 

The code for TYENT and TYEXIT is very short, but it is not simple. 
The first complication is that these programs are called as subroutines, 
which entails a return saved on the stack, while one of their jobs is to 
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!Terminal I/O context switching (non-segmented) 

CALL TYENT—establish context; leaves C unaffected 
CALL TYEXIT—restore context; leaves C unaffected 


Register use 
R0,R1 ares 
! TYCON = 


NTYCX = 
TYCXB = 
NTYRG = 
TYRGB = 


scratch registers 

= R2 IContextblock—same as at CONBLK in memory! 

= RH2 ITells what TYOUT is doing **MUST BE FIRST**! 
= RL2 !Current character! 

= R3 !Adr of next char for TYOUT to put out! 

= R4 !Adr of keyboard input buffer! 

= R5 !Adr of LINE of input being built! 

= R6 !Input and ! 

= R7 ! Output I/O addresses! 

= R8 ! Adr of last caller (Must be last saved register)! 

= 7 !Numb of registers in context! 

r 2*NTYCX !Each takes 2 bytes in mem! 

= NTYCX + 2 !Total, counting scratch registers! 

: 2*NTYRG 


TYENT: EX TYRT,@SR !Swap return off stack! 

DEC SR,#TYRGB-2 !Save the other registers! 

LDM @SR,RO,/i^NTYRG-l 

LDM TYCON,CONBLK,^NTYCX - 1 !Load context (except TYRT)! 
JP @TYRT ! Return to caller! 

TYEXIT: POP TYRT,@SR !Pop return into TYRT! 

LDM CONBLK,TYCON,;i^NTYCX !Update context! 

LDM RO,@SR,/(^NTYRG - 1 !Restore registers (except TYRT)! 

INC SR,#TYRGB-2 

EX TYRT,@SR; RET !Restore TYRT and exit! 


6.11: Context-Switching Routines for Terminal I/O 


save register values on the stack. Since we have to move the saved 
return out of the way of the saved registers, we make a virtue out of 
necessity and add the item TYRT to the context block; none of the 
routines use TYRT, but its presence may be a debugging aid someday 
when we least expect it. 
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Here are the steps by which TYENT and TYEXIT switch contexts: 

(1) TYENT swaps the current R8 value with the saved return on the 
stack, then it saves R0-R7 using the same technique we saw in Figure 3.9. 

(2) Then TYENT loads R2-R7 from the context block in memory, 
leaving R8 unchanged. 

(3) Finally, TYENT returns to the caller using the return saved in R8. 

(4) TYEXIT begins by popping the return address into R8. 

(5) Then TYEXIT saves R2-R8 in the context block in memory. 

(6) Finally TYEXIT restores registers R0-R8 (by reversing Step (1) 
above) and returns to the calling program. 

Notice that the success of this process depends on the fact that TYRT 
is last in the registers and that the scratch registers are first. We have 
to remember that fact if we ever add more to the context block; the 
new items must come somewhere after R1 and before TYRT. Then 
NTYCX has to be redefined. 

Figure 6.11 lets us write the routine TYOUT corresponding to 
Figure 6.9. This is shown in two parts in Figures 6.12 and 6.13. A few 
naming changes have been made to achieve relatively short names; 
otherwise. Figures 6.12 and 6.13 give a straightforward translation of 
Figure 6.9. 

The “If Case. . . go to . . . ” statements of Figure 6.9 have been 
implemented using the TRAN routine, which we present in Chapter 
VIII. It takes a value in RO, looks it up in an associative table like 
TYCO or CHRGO and replaces RO with the second entry of the first 
pair in which the original RO value is the first entry. For example, 
referring to TYGO, if the original RO value is ECSTR, TRAN will 
replace it with STREC. If the item isn’t found in the table, the de¬ 
fault value following the zero is returned. Also, TRAN uses C to indi¬ 
cate whether or not the item was found; this is similar to what is done 
in SAYNX, the short subroutine at the bottom of Figure 6.12. This 
is a useful way to return information from subroutines when the call¬ 
ing program may or may not care (e.g., with TRAN above we never 
looked at the C value that it returned). To make this scheme especially 
useful a consistent pattern should be followed. The one used in this 
book is 


C = 0: Normal, expected, non-error return 

C = 1: Abnormal, unexpected, error return 

For example, as we shall see in Chapter VIII, TRAN returns C = 0 if 
the item is found in the table, C = 1 if not. For routines that test 
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ITerminal Output Service Routine! 


TYOUT: CALR TYENT 


LDB RL0,FLAG; CLRB RHO 

!Use FLAG! 

LDA Rl, TYCO 

! andTYGO! 

CALL TRAN; JP@R0 


liable of processing addresses for various FLAG values! 

TYCO: INPUT; ECHO; ECSTR; STREC; 

OUTPUT; PRINT; 0; ERROR 

STREC: !String Echoing! 


CALR SAYNX; JR NC.TYEX 

!Put out next, exit if not end! 

LDB FLAG,/j^INPUT; JR ECHO 

!If end, go back to echoing! 

PRINT: !Printing! 


CALR SAYNX; JR NC,TYEX 

!Put out next, exit if not end! 

LDB FLAG,#DONE; JR TYEX 

!If end, say “done”! 

TYEX: JR ECEX 

!Finished processing interrupt! 

ERROR: JR ECEX 

!Should not be here—ignore! 

SAYNX: LDB RL0,@PTR; CPB RL0,)!TRM 

!Fetch next char, say if none! 

JR EQ,NOEX 


OUTB @IOUT,RLO; INC PTR 

!Put it out if not terminator! 

RESFLG C; RET 

!C = 0 if not end! 

NOEX: SETFLG C; RET 

!C = 1 if end! 


6.12: Terminal Output Service Routine (Except Echo) 

conditions, the C interpretation should depend upon the routine 
name. For example, if CHKRDY is a routine to check whether some¬ 
thing is “ready” or “busy,” then we should use 

C = 0: ready 
C = 1: busy 

Following a convention like this gives you one less thing to worry 
about, since you always know what the returned status means without 
having to look back at a listing of the routine. 

The character strings CRS, BSS and ESCS in Figure 6.13 are 
probably not in the form recognized by any particular Z8000 
assembler. The idea is that the characters whose symbolic names 
appear in parentheses will be assembled into consecutive bytes of 
memory starting at the one equated to the given label. It is also 
assumed that the assembler will add an extra zero byte if needed to 
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lEchoing Section of TYOUT! 

ECHO: LD R1,RING; CALL GETRNG !Next input char! 

JR NC,EC1 

LDB FLAG,<^fSLEEP; JR ECEX ISleep if none! 

ECl: LDB CHAR,RL0 !SaveCHAR! 

CLRB RHO; LDA Rl,CHRGO !Use CHRGO & CHAR 

CALL TRAN; JP @R0 

!Table of processing addresses for various CHAR values! 

CHRGO: RUBOUT;ECRUB; BS;ECRUB; CR;ECCR; ESC; ECES; 0; ECC 

ECRUB: !Rubbing! 

LD R1,LINE; CALL BACKUP 
JR C,ECHO 

LDA PTR,BSS; LDB FLAG,<^^ECSTR 
JR STREC 

BSS: BYTES(BS,SPACE,BS,TRM) 

ECCR: ! Terminating! 

LD R1,LINE; LDB RL0,ifrRM !Terminate LINE! 

CALL ADLINE 

LDA PTR,CRS;LDB FLAG,/^OUTPUT !EchoCR,LF! 

JR PRINT 

CRS: BYTES(CR,LF,TRM) 

ECES: !ESCing! 

LD R1,LINE; LDB RL0,CHAR !Add ESC to LINE! 

CALL ADLINE 

LDA PTR,ESCS; LDB FLAG,i^T:CSTR !Echo $,/! 

JR STREC 

ESCS: BYTES(‘$’,‘/’,TRM) 

ECC: !Character Printing! 

LD R1,LINE; LDB RL0,CHAR ! Add CHAR to LINE! 

CALL ADLINE 

OUTB @IOUT,CHAR !Print the character! 

ECEX: CALR TYEXIT; IRET !Switch context & IRET! 


6.13: Terminal Output Service Routine (Echo Section) 


!Pull back last char! 

! None to Pull! 
!Echo wipe out chars! 
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!Teriiiinal Input Service Routine! 


TYIN: CALR TYENT 

ISet up context! 

INB CHAR,@IOIN; CALL PUTRNG 

IGet and store character! 

CPB FLAG,ASLEEP; JR EQ,ECHO 

IWake up output if sleeping! 

CALR TYEXIT; IRET 

!Restore context & go! 


6.14: Terminal Input Service Routine 


assure that the following instruction (e.g., LD Rl, LINE after BSS) 
is assembled into an even address, and that the following label (e.g., 
ECCR:) will get the right value. Assemblers vary in the ways that these 
issues are handled; you must find out and use the conventions of your 
particular assembler. 

There is another point about these strings and about the tables TYGO 
and CHRGO: the way they are used forces them to be in data 
memory. This illustrates why separate data and instruction memory 
spaces should probably not be used for general purpose programming. 
Of course, if they are to be in separate spaces, the assembler will have 
to provide a way to make this happen, including assigning the right 
values to labels like BSS and TYGO. The loader will also have to 
provide for “initializing” data memory, and this will require a special 
purpose hardware configuration. 

The routines ADLINE and BACKUP for manipulating LINE and 
the routines GETRNG and PUTRNG (to be seen in Figure 6.14) for 
manipulating RING will be presented in Chapter VIII. LINE is simply 
a character array; RING is a first in, first out input buffer. Its name 
derives from its implementation as a ring buffer—the easiest way to 
implement a FIFO buffer in software. 

Finally, Figure 6.14 shows the input service routine TYIN. It follows 
the outline of Figure 6.10 quite closely. 

Several symbolic names have been used in the programs of Figures 
6.12, 6.13 and 6.14 that haven't been defined explicitly: CR, LF, BS, 
SPACE, TRM (= NUL, the terminate character) and the FLAG values 
INPUT, ECSTR, OUTPUT, SLEEP, DONE. For the FLAG values 
any distinct values in the range 1 to 255 will do. The others are symbolic 
names for ASCII characters, and must be given values corresponding 
to Figure 1.15. This completes the example. 
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EXERCISE 9: (a) Notice that the first instruction at ECRUB, ECCR, 
ECES, and ECC is LD R1,LINE; is there some way to avoid this repeti¬ 
tion? What about the LDB RL0,CHAR that appears at ECC and at 
ECES? What about the three appearances of CALL ADLINE? 

(b) Suppose that you wanted to handle half a dozen or so characters the 
way ESC is handled: put the character into LINE and echo a special string. 
Is there a uniform way to do this using TRAN and more tables? 

(c) Provide a TAB facility that stores the TAB character in LINE but 
echoes zero or more spaces to move the print head or cursor to the next 
in a table of tab stops. Assume that the address of the table is another 
item in the context. Make the necessary changes to the context definitions. 


EXERCISE 10: Write a segmented version of the terminal interrupt pro¬ 
cessing routines. What changes could make the two versions more similar? 

EXERCISE 11: In Chapter IX we shall find that we have the option of 
preventing interrupts from one of the terminal devices from happening 
while we are processing interrupts from the other. What would happen if 
execution of TYOUT were suspended to allow an input interrupt to be 
processed by TYIN? Or vice versa? Remember, each one has a copy of 
the context in registers, which it writes into memory when it is done. This 
problem will be discussed in Chapter VIII. 
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Chapter VII 

Z8000 Peripheral Components 


The Z8000 is designed to be part of a family of components sharing 
a common bus design and providing all of the pieces necessary to 
support the usual computer applications. The subject of how all of 
these components are put together is too broad to be covered 
adequately in this book; a Z8000 Applications Book is planned for 
future publication. In this chapter we shall give an overview of this 
component family and discuss the internal operations of the Z8000 
CPU that pertain to I/O. 

Special I/O Instructions 

We have alluded several times to the “special” I/O instructions 
designed for use with the memory management unit, which does not 
have access to the address/data bus lines AD7 - ADo and must use 
ADis-ADg for all address and data information. Here is a point of 
confusion: the original idea was to have the special I/O instructions 
use ADis-ADg to convey 16-bit address and data information; the 
way it wound up was that special I/O instructions work exactly like 
regular I/O instructions, using AD15 - ADo to convey 16-bit informa¬ 
tion. The only difference is that special I/O instructions produce 
one value on status lines ST3 - STo while regular I/O instructions pro¬ 
duce another. (See Figure 2.12.) 

What actually happens when the Z8000 CPU executes an I/O 
instruction? Exactly the same thing that happens to memory references: 
for a word reference 16 bits of address are output on AD 15 -AD 0 , 
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then 16 bits of data are output or input on the same lines. For a byte 
reference, 16 bits of address are again put out on ADis - ADo; then for 
output the 8 bits are put out on ADis-ADg and on AD7-AD0; for 
input the 8 bits are read from AD, 5 -AD 8 or from AD 7 -AD 0 , de¬ 
pending on whether the address was even or odd. 


The Memory Management Unit (MMU) 

What does this mean for the MMU? It cannot see AD7 - ADo, so it 
can only respond to ADis-ADg. The MMU responds to the 64 
patterns 00-3F on ADis-ADg, using them to address its various in¬ 
ternal registers, but it only does so when ST3-ST0 indicate “special 
I/O” status and its chip select signal is asserted. It is the responsibility 
of the system designer to provide external chip-select logic. This will 
be more or less complex depending upon the number of MMU’s in the 
configuration. The obvious arrangement is to use the top byte of the 
address (AD,5 - ADg) to address the internal register and the low byte 
(AD7 - ADo) to tell the chip-select logic which chip to select. AD7 - ADo 
can be used in any way the designer chooses, but Ao should always be 
zero. If Ao is not zero, the CPU will look at AD7 - ADo for byte input, 
since addresses with Ao set are odd. Since the MMU can only put sig¬ 
nals on AD,5 - ADg, all MMU addresses must be even; this means that 
the designer can use the seven lines AD7-AD1 to encode up to 128 
different MMU’s. If fewer than eight MMU’s are involved, each can 
be assigned one of the bits AD 7 to AD,. This has the advantage of sim¬ 
plicity and the further advantage that several MMU’s can be sent the 
same instruction simultaneously. This could be important in cases 
where two different MMU’s must have identical settings in some of 
their registers, especially if an interrupt occurring between the setting 
of one and the setting of the other could cause failure. An example of 
a configuration using this addressing scheme is worked out in detail in 
the Zilog publication An Introduction to the Z8010 Memory Manage¬ 
ment Unit—Tutorial Information by David Stevenson. 

We have not yet discussed the registers or the operation of an 
MMU. We shall now give a brief account of them. 

The MMU contains an array of 64 32-bit segment descriptor regi¬ 
sters, three one-byte control registers and six bytes of “violation in¬ 
formation” status. 

The segment descriptor register array is indexed by the last six bits 
of the segment number (SN5 - SNo). A bit in one of the control registers 
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determines whether the 64 segments are 0 to 63 or 64 to 127, that is, 
SN 6 = 0 or SNe = 1. Each segment descriptor contains a base address 
(specifying bits 23-8 of the physical base of the segment), a limit field 
specifying the number of 256-byte blocks of physical memory actually 
assigned to the segment (not all segments use the full 64K bytes avail¬ 
able) and eight “attribute” bits that specify whether the segment: 

• has been referenced 

• has been changed 

• is to receive special treatment intended for stacks 

• does not allow DMA access 

• is to be executed only 

• does not allow CPU access 

• does not allow normal mode access 

• is to be read only. 

The three one-byte control registers contain eight bits to act as a 
byte address register for references to the segment descriptor array, 
three bits to specify which one of AD, 5 - ADg this MMU will set in the 
“reason” for a segment trap and five bits that say whether the MMU 
will: 

• float its physical address lines 

• pass addresses in its range directly to physical memory untranslated 

• respond to segments 0-63 or to 64-127 

• respond to system mode, to normal mode or to both. 

The remaining eight bits are unused. 

The six one-byte violation information registers contain saved 
information about what caused the trap: 

• The upper 15 bits of the 23-bit segmented address that caused the 
trap 

• The upper 15 bits of the 23-bit segmented address of the last in¬ 
struction fetch 

• The N/S,R/W and ST 3 - STo status lines at the time of the trap 

• Eight bits describing the type of violation: 

• four corresponding to prohibitions set in the attribute bits 
(all except DMA) 

• one for exceeding the length specified by the limit field 

• two for various types of impending stack overflow 

• a “fatal” bit, used when errors accumulate. 

We shall not give detailed register layouts and internal addresses for 
the MMU. For these the reader is referred to the manufacturer’s 
documentation. 


PERIPHERAL COMPONENTS 213 



The Z8000 Component Family 


The following items make up the Z8000 component family: 

• Z8000CPU 

• Memory Management Unit 

• Serial Communication Controller 

• Counter/Timer & Parallel I/O Device 

• First In, First Out CPU/CPU or CPU/Peripheral Buffer 

• Direct Memory Access Controller 

• CRT Controller 

• Floppy Disk Controller 

• Z8-Based Universal Peripheral Controller. 


Serial I/O 

In the last chapter we talked about synchronous bit serial data 
transmission. We examined some of the problems involved in serial- 
to-parallel conversion, i.e., the extracting of eight-bit characters from 
the continuous bit stream. This function, and its complement, 
parallel-to-seriai-conversion, are usually performed by an integrated 
circuit. One such circuit, which can be used with the Z80(X), is the 
Z80A-SIO. It gives an idea of what such circuits are like. This 
component is described adequately in the manufacturer’s documenta¬ 
tion, so we shall not describe it in detail here. 

The purpose of a serial I/O circuit is to allow parallel transmission 
at the CPU end and serial transmission at the device end. The reason 
for wanting serial transmission at the device end is that there are 
generally accepted standards (e.g., RS-232C) for serial I/O. It is also 
better suited to transmission over long distances (requiring fewer wires 
and eliminating the problems of synchronizing signals transmitted in 
parallel). Modems and telephone lines can be used for serial trans¬ 
mission. But just as serial transmission is standard in some ways, it is 
also blessed with many options: baud rates, numbers of bits per 
character, numbers of stop bits, parity of characters, conventions for 
blocking and framing of transmitted records, longitudinal error 
checking and many more. Early serial I/O circuits (e.g., the UART) 
provided some of these options on the basis of signals presented at 
their input pins. A modern circuit like the Z80A-SIO has internal 
registers and is capable of being “programmed” by commands sent by 
the CPU. 
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Parallel I/O 


While serial I/O has standard conventions, parallel I/O has very 
few. The purpose of a parallel I/O component is to allow devices to be 
interfaced in a standard way, particularly with respect to the CPU’s 
conventions for interrupts and acknowledgement. The Z80A-PIO is 
such a circuit; it can be used with the Z8000. 


Counter/Timer Circuits 

The main purpose of a counter/timer circuit is to allow timing 
functions such as those necessary for bit serial synchronous trans¬ 
mission to proceed without the full attention of the CPU. The CPU 
programs the circuit to interrupt it at specified intervals. Whenever the 
interrupt happens, the CPU does whatever it was supposed to do (e.g., 
sample the input in the center of the bit time). The Z80A-CTC is such 
a circuit and can be used with the Z8000. 

We shall not go into further detail on the Z8000 component family; 
the purpose of a CRT or Floppy Disk Controller is obvious enough. 
The purpose of the First In First Out Buffer is simply to allow devices 
of different speeds to communicate without slowing the faster one 
down. The Direct Memory Access Controller allows data to be trans¬ 
ferred at memory speeds without CPU intervention. This is intended 
for devices that have very high data transfer rates (e.g., disks). 


Some Unplanned Features 

There are several Z8000 features that have profitable uses other 
than those for which they were originally intended. For example, in 
Chapter IV we talked about ways to make use of the “unimplemented 
instruction” trap. Another promising feature is the REFRESH 
register (see Figure 2.10). 

Suppose, for example, that the RATE field is set to 50 and the clock 
rate is 4 MHz; then the ROW field is incremented by 2 every 50 /xs. 
That means that if you want to wait 10 ms, all you have to do is check 
the current value of the ROW field, call any other routines that need 
to be executed, then come back and wait until the ROW field has been 
incremented by a total of 400 above the original value. You no longer 
need be concerned with the actual amount of time taken by the routines 
called (assuming that it is less than 10 ms). Many variations on this 
theme are possible. 


PERIPHERAL COMPONENTS 215 



Using the REFRESH register costs three clock cycles every time a 
refresh cycle happens (every 50//s in the above example). This refresh 
cycle can actually be used to implement a clock: external logic can 
cause an interrupt every time the ROW counter reaches 400 on a 
refresh cycle, and an interrupt routine can update a software clock by 
10 ms and subtract 400 from the ROW value. Unlike the previous 
example, this one assumes that the refresh circuitry is dedicated to this 
application. 

EXERCISE 2: (a) Why is 400 subtracted from the ROW value? Why not 
just reset it to zero? 

(b) Write the code to subtract 400 from the ROW value. What happens 
if the ROW counter has already reached 512 and recycled to zero before 
the interrupt is processed? How do you avoid disturbing the RATE field 
and the enable bit? What if it has already reached 288 (800 mod 512)? 

Another likely candidate for non-standard use is the multi-micro 
synchronization facility. This can be used for a one-bit I/O port. The 
MREQ instruction can be used to generate pulses of measured duration. 

EXERCISE 3: (a) Write the code to generate a pulse of 100 ms on MO. 

(b) Write code to input the MI value into the low order bit of a register. 

(Hint: remember TCC.) 

This concludes our discussion of the Z8(XX) peripheral components. 
The reader who wants to go further into this area is referred to the 
forthcoming Sybex publication: Z8000 Applications Book, 
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Chapter VIII 

Utility Programming Examples 


We can all think of examples of computer systems that don’t do 
much to help the user: a large batch processing system that requires 
job control parameters like a time limit or a maximum number of 
output lines to be specified in octal; a small interactive system that 
does not let you type ahead when you already know the answers 
before the questions are asked; the endless proliferation of large and 
small systems that cannot deal with dates in human-readable form. 
The sad thing about it is that most of these systems are put together by 
programmers who genuinely care about making them better. 

The principal problems are time and tools. It takes a long time to 
invent the wheel, as those of us who have done it many times will tell 
you. Or as someone else once put it, “We’ll get a lot higher standing 
on each other’s shoulders than we will stepping on each other’s toes.’’ 
Of course, one book cannot solve many problems, but if you use some 
of the wheels in this chapter, instead of reinventing them, you may 
have time left over to make some user’s life a little easier. 

The programs in this chapter will all be for the non-segmented 
Z8000. Analogous versions with different storage or register allocation 
for addresses are needed for segmented operation. 

The I/O Initiator 

In Chapter VI we presented the interrupt processing routines TYOUT 
and TYIN. Now we shall write the routine TYIO that initiates the 
operations carried on by TYOUT, but first we need a better idea of 
how this mechanism is meant to be used. 
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TYIO is a utility for application programs using the terminal. It is 
called to do one of two things: 

(1) Input a line from the keyboard. 

(2) Output a line to the teleprinter or screen. 

For example, the programmer may wish to output the message 

“Enter your password: ’’ 

and then accept a keyed-in response terminated by a carriage return. 
The first of these corresponds to (2) above, the second to (1). 

To input a line from the keyboard involves several complications, 
the first of which is echoing. If the operator types an “A”, then the 
program must send an “A” back to the printer/screen. The echoing 
must wait for any previously ordered output operations to finish. On 
the other hand, the operator may have typed the “A” before we even 
asked the question, so the keyboard interrupt processing routine must 
take in characters and save them until the program calls for input. 

Another complication of input is the handling of special characters. 
For example, the RUBOUT character needs special echoing, and it 
needs to cause the last previous character to be removed from the 
buffer in which the input line is being built. The echoing depends upon 
whether the terminal display is a CRT or a printer (the routine 
TYOUT of Chapter VI assumes a CRT), and it is suppressed 
altogether if there is nothing to rub out. 

Imagine in the above example that the operator starts typing a pass¬ 
word before the program requests it, pauses in the middle to 
remember some part of it, then finally finishes after the computer has 
caught up. Figure 8.1 shows a possible sequence of events. 

In one of the exercises of Chapter VI we alluded to some of the 
problems that could arise if the interrupt routines TYOUT and TYIN 
could interrupt each other. Fortunately, we can arrange that they do 
not do so. But they have to interrupt TYIO, since one of the things 
TYIO will have to do is wait for FLAG to be set to DONE. It will do 
this by looking at FLAG over and over until it is set to DONE; if there 
were no interrupts going on in the background, this would be an in¬ 
finite loop, since there would be no way for the setting of FLAG to 
change. 

Recall that the source of the problem of interaction was that there 
were two different copies of the context taken from the memory area 
at CONBLK and loaded into registers. Each program that took a copy 
wrote its copy back when it was done, so one of these copies had to 
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EVENT 

User types: G,U,M 


Program asks: 

"ENTER PASSWORD:" 
User types: R, RUBOUT. 



Final interrupt occurs 
after message has been 
output. FLAG is set to DONE. 

Program requests input. 
Processing begins. 

User types: D,R,0,P. 

TYOUT pulls RUBOUT 
from the input buffer and 
acts on it, removing R from 
the input line and echoing 
BS, SPACE, BS. 



TYOUT processes the next 
four characters. User has 
not yet pressed RETURN, so 
input is incomplete, but buffer 
is empty. 

FLAG is set to SLEEP. 

User presses RETURN. RETURN 

As TYIN places the RETURN 
into the input buffer, it sets 
FLAG back to INPUT and 
jumps into TYOUT. 



TYOUT pulls RETURN 
from the input buffer. It 
echoes CR,LF and 
stores NUL in the line 
buffer. 

FLAG is set to DONE. 



8* 1: Sequence of Events in Keyboard Input 
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wind up being written over the other—any changes made to the first 
copy would be lost when the second copy was written on top of it. 

If TYIO uses TYENT and TYEXIT to set up and save the context 
and if TYIO is interrupted by TYOUT or TYIN, then any change 
made by TYOUT or TYIN to the context (e.g., setting FLAG = DONE) 
will be lost. Since TYIO must wait for FLAG to be set to DONE, this 
waiting must be accomplished without reading and updating the 
context block. After FLAG is set to DONE, TYIO is free to use the 
context block, since when FLAG = DONE, there should be no TYOUT 
interrupts, and the TYIN interrupts leave the context unchanged. 

Figure 8.2 shows the TYIO routine. The TYWAIT routine at the 
bottom looks at the copy of FLAG in memory, using the fact that it is 
the first byte of the context at CONBLK. This accounts for the 
comment ***MUST BE FIRST*** in the definitions for TYENT and 
TYEXIT. 

EXERCISE 1: Consider the following possible approach to avoiding 
having two routines with copies of the context. 

Let the first word of CONBLK be a semaphore: when it has the value 
- 1, the context is unavailable for use; when it is zero, the context can be 
taken and used. The sequence 

X: TSET CONBLK; JR MI,X 
must precede any reading of the context; a 

CLR CONBLK 

must follow the writing of the context back. 

Then TYENT can be written with a line 

TYWSM: TSET CONBLK; JR, MI,TYWSM 
preceding its fetch of the context; TYEXIT can have the 
CLR CONBLK 

inserted right after it restores the context. All routines calling TYENT and 
TYEXIT would have their access to the context block controlled auto¬ 
matically. 

Now TYWAIT can be written 

TYWAIT: CALL TYENT 

CPB FLAG,#DONE; JR EQ,TYWEX 
CALL TYEXIT; JR TYWAIT 
TYWEX: CALL TYEXIT; RET 
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!Terminal I/O initiator (non-segmented) 


CALL TYIO; R1 = adr of argument table 
Returns C = 0 if initiated 

C = 1 if command invalid. 

I/O proceeds under interrupt. 

CALL TYWAIT 

Returns when previous operation is complete. 


Argument table format: 

Byte address 

PFLAG = 0 
PADR = 2 
POUTA = 4 
PRING = 6 

!Table Lengths (bytes): 


For Input Request 

ItflNFVT 
! Address of LINE 
!Output I/O address 
! Address of RING 
! LINTAB = 8; 


For Output Request 

^OUTPUT ! 

Address of output string! 
Output I/O address 
(not used) 

LOUTAB = 6 

IWait for “done”! 

ISet context! 

!Set FLAG from table! 

! and output I/O adr! 

! If input: ! 

! Set RING! 

! &LINE! 

!Else if output: ! 

! Set PTR! 

!Else error! 

! OK exit: C = 0! 

! Initiate I/O! 

! Error :C = 1! 

!FLAG = DONE! 


TYIO: CALR TYWAIT 

CALR TYENT 
LDB FLAG,R1(/«»FLAG +1) 

LD IOUT,Rl(#POUTA) 

CPB FLAG,#INPUT; JR NE,TY1 
LD RING,R1(#PRING) 

LD LINE,R1(#PADR) 

JR TYOKX 

TYl: CPB FLAG,/5^0UTPUT; JR NE,TYERX 

LD PTR,R1(^^T»ADR) 

TYOKX; RESFLG C;CALRTYEXIT 
SC #IOGO; RET 
TYERX: SETFLGC 

LDB FLAG,#DONE 
CALR TYEXIT; RET 


!Waiting routine! 

TYWAIT; CPB CONBLK,#DONE; JR NE,TYWAIT; RET 


8.2: Terminal I/O Initiator 
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If a TYIN or TYOUT interrupt occurs between TYWAIT’s TYENT and 
TYEXIT calls, the interrupt routine will call TYENT and will stay in the 
loop at TYWSM until TYWAIT finishes its test and puts back the context. 

Then interrupt processing will proceed, and TYWAIT will not eradicate 
any changes made by TYIN or TYOUT. 

Why won’t this work? The situation that makes it fail is called a deadly 
embrace. 

There are other points worth noting in Figure 8.2. The calling argu¬ 
ments are passed in a table addressed by Rl. The positions of the 
arguments in the table are defined and documented simultaneously, 
and the defined table positions are used inside the routine with the 
based addressing mode. Since this routine is written for non-seg- 
mented operation, we could also have used indexed addressing (e.g., 
LD IOUT,POUTA(Rl) instead of LD IOUT,Rl(#POUTA)), but 
this would make our task harder when we came to write the anedogous 
routine for segmented operation. In fact, if we were to provide the 
definition 


TABADR = Rl 


at the beginning of the routine (perhaps on the same line as “Rl = adr 
of the argument table”), and wrote, for example, 

LDB FLAG,TABADR(#PFLAG-hl) 


instead of 


LDB FLAG,R1(#PFLAG +1) 

then the only change needed for this routine to go to segmented opera¬ 
tion would be a redefinition like 

TABADR = RR2 

But of course TYENT and TYEXIT would need to be rewritten to 
provide different register allocation. 


EXERCISE 2: Write versions of TYENT and TYEXIT that provide an 
appropriate register allocation for segmented operation. Can a device 
similar to the definition TABADR mentioned above be used to localize 
the necessary source changes? 
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Finally, note that the 


SC #IOGO 

instruction follows the call to TYEXIT. Recall that this is a device (to 
be discussed in Chapter IX) for simulating a terminal output inter¬ 
rupt, since no character has yet been sent to the terminal in response to 
the final interrupt from the last output task (the one that caused 
FLAG to be set to DONE). Why does it follow the TYEXIT call? 


Ring Buffer Routines 

In Chapter VI we used a ring buffer for the terminal input buffer. A 
ring buffer is simply a first in, first out buffer, and it can be used in 
many applications. The basic maintenance routines are GETRNG and 
PUTRNG. Some initialization is required for the approach used here, 
but it is straightforward, and we shall not go into it. 

Figure 8.3 shows the calling sequences for these routines and the 
format of the ring buffers they support. The storage portion is an 
array of n bytes. It is called a ring because byte 1 is treated like the 
next byte after byte n. There are two pointers moving around the ring. 
The put-pointer points at the next free slot, where the next item will be 
added; the get-pointer points at the oldest item in the buffer, the next 
to be removed. 

A byte position is empty if it contains a zero (so zero items cannot 
be stored in it; this is fine for characters). If the get-pointer is pointing 
at a zero item, the buffer is empty. If the put-pointer is not pointing at 
a zero item the buffer is full. Whenever GETRNG removes an item via 
the get-pointer, it replaces it with a zero. Figure 8.5 illustrates this. 

Because of the problems we had with the context block for the 
terminal I/O routines, we use a slightly different approach here. 
RNGENT reads the context block into the registers from the front of 
the ring. RNGEX does not write the whole context back out. Instead, 
GETRNG writes the updated get-pointer directly into memory, and 
PUTRNG writes the updated put-pointer. 

The use of an index (0 to n - 1) for the pointers makes the ring, as a 
data structure, independent of its location in memory and also 
independent of the segmentation mode. Of course, the programs that 
maintain rings assume non-segmented operation (e.g., using R1 as an 
address register), but the rings themselves contain no addresses. 
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!Ring buffer routines (non-segmented) 


CALL GETRNG; R1 = address of ring 

Returns C = 0 and next char in RLO or C = 1 if empty 

CALL PUTRNG; R1 = address of ring; RLO = character 
Returns C = 0 if stored, C = 1 and char ignored if full 

Format of a ring: 

First word: n (number of storage bytes in ring) 

! RGET = 2 !2nd word = Get-pointer (0 to n-1)! 

RPUT = 4 !3rdword = Put-pointer (0 to n-1)! 

RDAT = 6 IStart of n bytes of storage! 


jister use: 


R0,R1 communicate with caller 

RSCR 

= 2 

!R2,R3 are scratch! 

RNGCON 

= R4 

!Context block of registers! 

RSIZ 

= RNGCON 

!Ring storage size! 

GETP 

= RNGCON-hi 

! Get-pointer! 

PUTP 

= RNGCON+2 

! Put-pointer! 

RNGRT 

= RNGCON+3 

!Last caller—not in ring header! 

NRNCX = 

3 

!Number of registers for header! 

RNCXB = 

2*NRNCX 

!Number of bytes to store on stack! 

NRNRG = 

NRNCX + RSCR 

!Registers for header -f scratch! 

RNRGB = 

2*NRNRG 

!Total number of bytes! 


!Context saving & restoring routines: 

CALL RNGENT (Save registers, set context) - C preserved 
CALL RNGEX (Restore registers) - C preserved ! 


8*3: Ring Buffer Formats and Definitions 

EXERCISE 3: (a) Rewrite the terminal I/O routines in such a way that 
TYEXIT does not write out the context block. Provide definitions like 
RGET, RPUT, RDAT (Figure 8.3) for FLAG, PTR and other changing 
items, and use 


LDA R2,CONBLK 

to set a base address. Use the based addressing mode to allow TYOUT 
and TYIO to update changed items. The register context will have to be 
moved down one place, i.e., FLAG = RH3, CHAR = RL3, PTR = R4, 
etc. 

(b) Since TYIN makes no changes to the context, this might save over- 
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!Ring routines: RNGENT, RNGEX, GETRNG, PUTRNG! 


RNGENT: 

EX RNGRT,@SR 

ISwap return into RNGRT! 


DEC SR,#RNRGB 

LDM @SR,R2,#NRNRG 

ISave other regs-not RO, R1! 


LDMRNGCON,@Rl,#NRNCX 

ILoad context! 


JP @RNGRT 

lEXIT! 

RNGEX: 

POP RNGRT,@SR 

IPop return into RNGRT! 


LDMR2,@SR,#NRNRG 

INC SR,#RNRGB 

!Restore saved registers! 


EX RNGRT,@SR; RET 

!Restore RNGRT & exit! 

GETRNG: 

CALR RNGENT 

!Set up context! 


LD R2,GETP; INC R2,#RDAT 

!Adjust for ring header inf! 


LDB RL0,R1(R2); TESTB RLO 

JR Z.RGER 

!Load char; check for empty! 


CLRB RL3; LDB R1(R2),RL3 

!Replace char by zero! 


INC GETP 

!Increment get-pointer! 


CP GETP.RSIZ 

JR LT.GPUP 

SUB GETP.RSIZ 

! Reduce it modulo n! 

GPUP: 

LD Rl()mGET),GETP 

!Update Get-ptr in memory! 

RGOK: 

RESFLG C; CALR RNGEX; RET 

!OKexit:C = 0! 

RGER: 

SETFLG C; CALR RNGEX; RET 

!Empty/Full: C = 1! 

PUTRNG: 

CALR RNGENT 

!Set up context! 


LD R2,PUTP; INC R2,#RDAT 

!Adjust for ring header inf! 


LDB RL3,R1(R2); TESTB RL3 

JR NZ.RGER 

!See if slot empty! 


LDB R1(R2),RL0; INC PUTP 

!Store char, bump ptr! 


CP PUTP.RSIZ 

JR LT.PPUP 

SUB PUTP.RSIZ 

! Reduce ptr mod n! 

PPUP: 

LD R1(#RPUT).PUTP 

!Update Put-ptr in memory! 


JR RGOK 

!Take OK exit! 


8.4: Ring Buffer Routines 

head in processing keyboard interrupts. Compute typical times spent in 
TYIN for the current version of the routines and for your version. 

(c) Now suppose that a terminal output interrupt occurs while TYIN is 
executing inside its call to PUTRNG. What effect can this have? 
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Put-Pointer 


Get-Pointer 



01234 5 n -4 n -3 n -2 n-1 


The ring contains the characters 

G,U,AA,D,R,BS 

The next coll to GETRNG will return the G, place a NUL in slot n —2 and 
update the Get-Pointer to contain n — 1. 

The next call to PUTRNG will place a character into slot 4 and update 
the Put-Pointer to contain 5. 

8.5: Operation of a Ring Buffer 


The Line Handling Routines 

The routines ADLINE and BACKUP for handling the input line 
being constructed by TYOUT as it processes characters from the ring 
buffer are extremely straightforward. 


EXERCISE 4: You have just come onto a programming project and are 
given the code of Figure 8.6 exactly as it was left when the programmer 
took another job two months ago. 

(a) Figure out the calling conventions for BACKUP and ADLINE. 
(Hint: find where they are called in Chapter VI.) 

(b) What is the “format” of a line? 

(c) What happens if ADLINE is called with a full line? 
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!Example of how not to write a program! 


BACKUP: 

PUSHL @SR,RR2 

ISave R2,R3! 


LD R2,R1(#2) 

IGet the pointer! 


TEST R2 

ITest it! 


JR MI,LNER 

! Empty! 


LD R3,yif4 

!Offset of data storage part of line! 


ADD R3,R2 

!Add the pointer! 


LDB RL0,R1(R3) 

!Get the character! 


DEC R2 

!Decrement the pointer! 


LD Rl(<^f2),R2 

!Put it away! 

LNOK: 

RESFLG C 

! Clear C! 

LNEX: 

POPL RR2,@SR 

! Restore R2,R3! 


RET 

! Return! 

ADLINE: 

PUSHL @SR,RR2 

!Save R2,R3! 


LD R2,R1(#2) 

!Get the pointer! 


LD R3,R2 

!Put it in R3! 


INC R3 

! Increment R3! 


CP R3,@R1 

!Compare with line size! 


JR EQ,ADL1 

!Line full! 


LD R2,R3 

!Use R3! 


CLR R3 

!Zero means wasn’t full! 

ADLl: 

LD R1(#2),R2 

!Store pointer! 


ADD R2,#4 

!Add data offset! 


LDB R1(R2),RL0 

!Store character! 


TEST R3 

!Check for line full! 


JR Z,LNOK 

!Not full! 

LNER: 

SETFLG C 

!SetC! 


JR LNEX 

!Go to exit! 


8.6: BACKUP and ADLINE 


The Translation Routine 

TRAN is the simplest program in this chapter, and it is the most 
useful. There are many possible variations, but in its simplest form 
TRAN steps through a table of pairs of items trying to match the item 
it is searching for with the first item of each pair; if it finds a match it 
gives back the second item. This technique is called an associative 
search. 
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At first this routine doesn’t seem like much. In Chapter VI we saw 
how it could be used to implement a transfer to one of a number of 
possible locations based upon the value of a flag or a character. Later 
there will be other examples. Once you get into the habit of using 
TRAN, you will find applications for it cropping up all the time. 

Figure 8.7 shows TRAN. There are many ways to vary this basic 
routine: different item sizes, different translated value sizes, different 
action on failure. 

To the best of the author’s knowledge the idea of canonizing the 
associative search technique in a general purpose routine like TRAN is 
due to R.S. Langer. 

EXERCISE 5: For each of the thirty-one day numbers that occur in dates 
there is a usual suffix (e.g., 1st, 2nd, 3rd, 4th); make a TRAN table that 
gives these suffixes. To make it short, let the default suffix be the most 
common one. 


!Translation routine (non-segmented) 


CALL TRAN; RO = item to translate 


R1 = adr of table 


Returns C = 0 and RO = translated item, if found; 

C = 1 and RO = default value, if not found. 

Returns R1 = adr of item returned (translated item or default value) 

Format of table: 


Item I; Translated value of Item 1 

• 


• 

Item n; Translated value of Item n 


0; Default 

f 


TRAN: TEST@R1; JREQ.TRANF 

ILook for terminator! 

CPR0,@R1; JR EQ,TRANS 

IThen check for match! 

INC Rl,^4; JR TRAN 

!Try the next pair! 

TRANE: SETFLG C; JR TROUT 

!Not found! 

TRANS: RESFLG C 

!Found! 

TROUT: INCR1,))(2;LDR0,@R1 

!R1 points at value! 

RET 



8.7: The TRAN Associative Search Routine 
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TRAN is the last of our loose ends from Chapter VI. The next 
example will show how the initiator routine TYIO is used. 

Terminal Interation Package 

If a human being is to interact with a computer system, then the 
system should provide the programmer with the tools necessary to 
design such an interaction. The package discussed here provides a few 
basic tools. Possibilities for expansion or improvement are indicated 
and left as exercises. The bare bones package consists of four routines: 
SAY, ASK, GETCH, BACKCH. 

SAY takes the address of a terminated string and puts it out to the 
terminal. 

ASK takes the address of a (possibly zero-length) terminated string 
(the question), which it outputs to the terminal, then it accepts input 
(the answer), which is stored in a buffer called INLINE. Finally, it 
initializes INLINE’s pointer for use by GETCH and BACKCH. 

GETCH takes the next character out of INLINE and gives it to the 
caller; C is used to notify the caller of “end-of-line.” 

BACKCH “puts back” the character passed by the caller. The idea 
is that, for example, a number input routine takes in characters until it 
sees a non-digit. Then it uses BACKCH to put back the non-digit. 

Figure 8.8 defines the line data structure: it is the same as a ring, but 
with only one pointer, which does not wrap around from position 
n - 1 to position 0. This pointer also has the additional value - 1 to 
signify an empty line. As with a ring, a line is a data structure that is 
independent of segmentation mode; the maintenance routines are 
written assuming non-segmented operation. 

Figure 8.9 shows the routines GETCH and BACKCH and the two 
routines ADLINE and BACKUP presented earlier (see Figure 8.6). 
The approach to the presentation of Figure 8.9 is called top down: the 
main routines appear first; they deal with the data structure at a high 
level of generality. That is, the main routines make no assumptions 
about the implementation. They increment or decrement the pointer 
and they fetch or store a character using the primitives LINC, LDEC, 
LFETCH and LSTORE. The next level implements these primitives in 
terms of the particular representation chosen for the data structure. 
The context switching routines appear at the end. They are virtually 
identical to those for the ring routines. 


EXERCISE 6: Compare the routines of Figure 8.6 with those of Figure 
8.9. Which representation is clearer? Which has better comments? 
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!Line Routines 

CALL ADLINE; RLO = char 

R1 = adrofline 

Returns with character added (char overwrites last char if line full) 
CALL BACKUP; R1 = adrofline 

Returns C = 0 and last char in RLO; or C = 1 if line empty 
CALLGETCH;R1 = adrofline 

Returns C = 0, RLO = next char; or C = 1,RL0 = 0 if at end 

CALL BACKCH; RLO = char to replace; R1 = adrofline 
Returns C = 0 if char replaced; orC = 1 if no previous GETCH 


Format of a line: 

First word: n (number of storage bytes in line) 

LPTR =2 !2nd word: ptr (0 to n-1, - 1 if empty)! 

LDAT = 4 !Start of n bytes of storage! 


! Register use: 

! LSCR = 1 
LCON = R3 
LNSZ = LCON 
LNPT = LCON + 1 
LNRT = LCON+ 2 


!R0,R1 for call; R2 is scratch! 
!Context block in registers! 
!Line size! 

! Pointer! 

!Last caller—not in header! 


NLNCX = 2 !Number of registers in header! 

NLNRG = NLNCX + LSCR !Number including scratch! 
LNCXB = 2*NLNCX; !Bytes for the above! 

LNRGB = 2*NLNRG 


!Context saving and restoring routines 

CALL LNENT (Save registers, set context)—C preserved 
! CALL LNEX (Restore registers)—C preserved 


8.8: Definitions and Formats for Line Routines 


Figure 8.10 shows the routines SAY and ASK. Each of them uses its 
input argument to set up an argument table for a TYIO call. The 
buffers INLINE and INRING and the I/O address TYOUTP are 
assumed to be defined elsewhere. In Chapter IX, when we discuss an 
elementary “event-driven” timesharing system, we shall see that 
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JLine routines; GETCH, BACKUP, ADLINE, BACKCH! 

ADLINE; 

CALR LNENT 

CALRLINC; CALR LSTORE 

CALR LNEX; RET 

BACKUP: 

CALR LNENT 

CALR LFETCH; CALR LDEC 

CALR LNEX; RET 

GETCH; 

CALR LNENT 

CALR LFETCH; TESTB RLO; JR Z,GTER; CALR LINC 

CALR LNEX; RET 

GTER; 

SETFLG C; CALR LNEX; RET 

BACKCH; 

CALR LNENT 


CALR LDEC; CALR LSTORE 


CALR LNEX; RET 

!Increment or decrement line pointer! 

LINC; 

LD R2,LNPT; INC R2; CP R2,LNSZ; JR GE,LNER 

INC LNPT; LD R1(#LPTR),LNPT; JR LNOK 

LDEC: 

TEST LNPT; JR Ml,LNER 

DEC LNPT; LD R1(#LPTR),LNPT; JR LNOK 

!Fetch or store via line pointer! 

LSTORE: 

TEST LNPT; JR MI,LNER 

LD R2,LNPT, ADD R2,i!'LDAT; LDB R1(R2),RL0; JR LNOK 

LFETCH; 

TEST LNPT; JR M1,LNER 

LD R2,LNPT; ADD R2,#LDAT; LDB RL0,R1(R2) 

LNOK: 

RESFLGC; RET 

LNER; 

SETFLG C; RET 

!Context switching on entry and exit! 

LNENT; 

EX LNRT,@SR; DEC SR,#LNRGB; LDM @SR,R2,ii'NLNRG 

LDM LCON,@Rl,#NLNCX; JP @LNRT 

LNEX; 

POP LNRT,@SR; LDM R2,@SR,#NLNRG; INC SR,#LNRGB 

EX LNRT,@SR; RET 


8.9: Line Routines 
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ITerminal interaction routines 

CALL SAY; R1 = adr of zero-terminated string 

CALL ASK; R1 = adr of question 

Returns with answer available for processing by GETCH and BACKCH 

j 

SAY: PUSH ©SR.Rl 

!Save string adr! 

DEC SR,#LOUTAB 

!Build TYIO table on stack! 

LD SR(/J^PADR),R1 

! ADR = string address! 

LDRl,#OUTPUT 

! FLAG = “output”! 

LD SR(#PFLAG),R1 

LD RL^YOUTP 

! OUTA = I/O address! 

LD SR(#POUTA),Rl 
LDR1,SR;CALL TYIO 

!Initiate the output operation! 

INC SR,^LOUTAB 

!Restore stack! 

POP R1,@SR; RET 

! Restore string adr; exit! 

ASK: CALRSAV 

!Output the question! 

PUSH @SR,R1 

!Save question adr! 

DEC SR,^LINTAB 

!Build TYIO table on stack! 

LDR1,#INPUT 

! FLAG = “input”! 

LD SR(#PFLAG),R1 

LDA Rl,INLINE 

! ADR = adr of INLINE! 

LD SR(#PADR),R1 

LD Rl,#TYOUTP 

! OUTA = I/O address! 

LD SR(#POUTA),Rl 

LDA Rl,INRING 

! RING = adr of INRING! 

LD SR(#PRING),R1 

LDA Rl,INLINE; CALL EMPLIN 

!Initialize input line! 

LDR1,SR;CALL TYIO 

!Initiate input! 

CALL TYWAIT 

!Wait until done! 

INC SR,#LINTAB 

!Free the table from the stack! 

LDA R1,INLINE; CALL SETLIN 

!Initialize for GETCH, BACKCH! 

POP R1,@SR; RET 

!Restore question adr; exit! 

! Another piece of the line routines 

SETLIN: PUSH @SR,R0; CLR RO 

!Borrow RO! 

LD R1(#LPTR),R0 

!Point at first char! 

POP R0,@SR; RET 

! Restore RO! 


8.10: ASK and SAY 
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these items become implicit arguments of SAY and ASK that vary 
from user to user. 

The symbols LINTAB, LOUTAB, PFLAG, etc., are defined in 
Figure 8.2. The argument tables for SAY and ASK can be kept on the 
stack and released as soon as TYIO returns, since the information 
necessary to support the ongoing operation initiated by TYIO is taken 
from the table by TYIO and set up in CONBLK. (Of course, this 
requires that data memory and stack memory coincide.) On the other 
hand, items like the string to be output cannot be left on the stack, 
since CONBLK contains only a pointer to the string, not the string 
itself. In order for a string like the one pointed to by R1 for SAY to be 
stored on the stack, a way would have to be found to avoid releasing 
the stack space until the actual printing is completed. An alternative 
would be to have a line called OUTLIN, similar in function to the 
other fixed buffers INLINE and INRING; then a SAY function could 
be implemented that moved the string into OUTLIN and called TYIO 
with ADR pointing at the text portion of OUTLIN. 

EXERCISE 7: Write a routine called SAYF that behaves as suggested in 
the previous paragraph. What is the best way to get the address of the text 
portion of OUTLIN? What is the most efficient way to move the string 
into OUTLIN? How do you assure that OUTLIN is free before moving 
the string into it? 


Input Decoding 

The routines GETCH and BACKCH can be used to implement a 
number of input decoding routines. Since ASK uses INLINE 
implicitly, it makes sense to have a pair of routines GETC and 
BACKC that do the same. These are shown at the bottom of Figure 
8 . 11 . 

Figure 8.11 is an illustration of the type of input line processing that 
is often useful in interactive programming. The programmer might 
use a call to ASK to display a prompting message and wait for a 
command input. The “fields” of the answer can be obtained one at a 
time using GETFLD. For example, if the input line consists of 

LOAD “Game Program”,!, FFOO 

then successive calls to GETFLD will return zero-terminated ASCII 
character strings for 
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!Get next ‘ 

‘field’’ from input line 


CALL GETFLD: R1 = adr of buffer to store field in 


R2 = buffer size (bytes) 


Returns RLO = separator “white space’’ following the separator is skipped; 

anything between quotes (“) is passed intact; R2 = 

f 

unused bytes (neg = overflow) 

GETFLD: 

PUSH @SR,R1; CURB RHO 

!Set flag: not in quotes! 

GETL: 

CALL GETC 

INext input char! 


JR C,GETEND 

!C means EOL! 


CPB RLO,/j^QUOTE 

!If quote, reverse flag! 


JR NE.GETl; COMB RHO 


GETl: 

TESTB RHO; JR NZ,GET2 

!If in quote string, pass it! 


CALL CKSEP; JR NC,GETEND 

!Else check for separator! 

GET2: 

DEC R2; JR MI,GETL 

!See if room to store it! 


LDB @R1,RL0; INC Rl; JR GETL 

!If room, store & bump ptr! 

GETEND: 

DEC R2; JR PL, GET3; DEC Rl 


GET3: 

CLRB@R1 

!Store zero terminator! 


CALL SKBLNK 

!Skip white space! 


POP R1,@SR; RET 


CKSEP: 

PUSHL @SR,RR0; CLRB RHO 

!Save RO, Rl; prepare RO! 


LDA Rl,SEPTAB; CALL TRAN 

!Is char a separator?! 


POPL RRO, @SR 

!Restore RO, Rl! 


RET 

!Pass TRAN’S C! 

SEPTAB: 

COMMA;0; SEMIC;0; SPACE;0; TAB;0; 0;0 

SKBLNK: 

PUSHL @SR,RR0 

!Save R0,R1! 


CLRB RHO 

!Prepare for TRAN! 

SKL: 

CALL GETC; JR C,SKEX 

!Get next char! 


LDA RLWHITAB 

!White space table! 


PUSH @SR,R0; CALL TRAN 

!ls it white space?! 


POP R0,@SR; JR NC,SKL 

!If so, get next! 


CALL BACKC 

!Else put it back! 

SKEX: 

POPL RR0,@SR; RET 


WHITAB: 

SPACE;0; TAB;0; 0;0 


GETC: 

PUSH @SR,R1; LDA RI,INLINE; CALL GETCH 


POP RI,@SR; RET 


BACKC: 

PUSH @SR,R1; LDA R1,INLINE; CALL BACKCH 


POPRl,@SR; RET 



8.11: Sample Input Line Decoding Routines 
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LOAD 


“Game Program” 


1 

FFOO 

The calls to GETFLD would be interspersed with calls on “recognizer” 
routines designed to examine a zero-terminated string to recognize a 
particular type of argument. For the above example we might have a 
command recognizer, a file name recognizer, a disk unit number 
recognizer and a memory address recognizer. Figure 8.12 shows how 
that code might look. Notice how repetitive it is. In fact, this type of 
application is ideal for a table-driven approach: an array of four two- 
item entries describes it completely. That is, a general program could 
be written to accomplish the same thing by processing a table of the 
form 


RECCMD;CMD; RECFIL;FILCOD; 

RECDSK;UNIT; RECADR;MEMADR 

EXERCISE 8: Write a version of the code in Figure 8.12 that takes the 
address of the above table and achieves exactly what Figure 8.12 achieves. 

How would you modify your program so that a variable number of fields 
could be specified? 

Much of the regularity of Figure 8.12 derives from the uniform con¬ 
ventions used by the routines RECCMD, RECFIL, RECDSK and 
RECADR: each takes arguments in the format returned by GETFLD, 
returns C = 0 and a one-word code for the recognized item in RO, 
or returns C = 1 if the string is not in the proper format. Figure 8.13 
shows a command recognizer that uses a technique of cascading TRAN 
tables. The symbols in the tables at the bottom are assumed defined 

elsewhere. AS_E, AS_L, etc., have values equal to the ASCII codes 

for E, L, etc. C_EDIT, C_LIST, etc., are small distinct numbers 

distinguishing the commands, e.g., C_EDIT = 1; C—LIST = 2; 

etc. These can later be used in a TRAN table like TYGO or CHRGO 
from Figures 6.12 and 6.13 to transfer to the appropriate processing 
routine. NXCH is a routine to get characters out of the buffer pointed 
to by Rl. 
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ISample Input Processing Code! 

DEC SR,^BUFL; LD R3,SR 
REASK; LDA Rl,PROMPT; CALL ASK 

IMake buffer on stack! 

1 Ask for command line input! 

LD R1,R3;LD R2,/mUFL 

CALL GETFLD 

CALL RECCMD; JR C,REASK 
LD CMD.RO 

! 1st field: Command code! 

LD R1,R3; LD R2,#BUFL 

CALL GETFLD 

CALL RECFIL; JR C,REASK 

LD FILCOD,RO 

!2nd field: File code! 

LD R1,R3; LD R2,#BUFL 

CALL GETFLD 

CALL RECDSK; JR C,REASK 

LD UNIT,R0 

!3rd field: Disk number! 

LD R1,R3; LD R2#BUFL 

CALL GETFLD 

CALL RECADR; JR C,REASK 
LD MEMADR,R0 

!4th field: Memory address! 

INC SR,#BUFL 

!Release stack buffer! 


8.12: Sample Input Processing Code 


The material in Figures 8.11, 8.12, and 8.13 is an illustration of the 
kinds of tools that can be built for input handling; much more is 
possible than is shown here. 

EXERCISE 9: (a) Write the routine NXCH called in Figure 8.13. It should 
behave as follows: 

If R1 = - 1, call GETC and return. 

Otherwise LDB RL0,@R1; if RLO t 0 then INC R1 and return 
C = 0; if RLO = 0, return C = 1. 

The purpose of this routine is that whatever code we write for processing 
strings in buffers can also be used to process the input string in INLINE. 

(b) How would the tables of Figure 8.13 change if the command ERASE 
were to be added? 

(c) Notice how often we have to clear RHO before using TRAN to trans¬ 
late a character read by GETC, GETCH, NXCH, etc. Some possible 
changes would be: provide a version of TRAN for translating characters 
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ICommand Recognizer! 


CALL RECCMD; Registers as set by GETFLD 
Returns C = 0 and cmd code in RO 
C = 1 if not recognized 

The program looks at the input characters one at a time; at each point, if what 
has been seen uniquely defines a command or can’t possibly match a command, 
then an appropriate return is made; otherwise the program continues to examine 
characters. This is accomplished by a cascade of TRAN tables: the first translates 
each possible initial character either into a command code or into the address of 
another TRAN table of possible second characters for that initial character, and 
so on. Command codes are distinguished from addresses by having 2 * code + 1 
represent a code; addresses are never odd. 

RECCMD: CLR RO; PUSH @SR,R1 Unitialize! 

LDA R1,TBLZER 

RCMDLP: EX R1,@SR; CALR NXCH INext char—fail if none! 

EX R1,@SR; JR C,RCMDER 

CALL TRAN; JR C,RCMDER !Translate—fail if can’t! 

RESFLG C 

RRC RO; JR C,RCMDOK ! If code, exit! 

RLC RO !Else TRAN table for next! 

LD R1,R0; CLR RO; JR RCMDLP 
RCMDOK; RESFLG C; POP R1,@SR; RET 
RCMDER: SETFLG C; POP R1,@SR; RET 

TBLZER: AS E; 2*C EDIT + 1; AS_L; TB_L; AS_P; TB_P 
AS_T; TB_T; 0;0 

TB_L: AS_I; 2*C_LIST + 1; AS_0; 2*C_LOAD + 1;0;0 

TB_P: AS_R; TB_PR; 0;0 

TB_PR; AS_1; 2*C_PRINT +1; AS_0; 2*C_PROGRAM + 1;0;0 

TB_T: AS E; 2*CTEST + 1; AS_I; 2*C_TIME + 1 

AS_Y; 2*C_TYPE+ 1; 0;0 

!Above tables recognize commands from the following list: EDIT, LIST, LOAD, 
PRINT, PROGRAM, TEST, TIME, TYPE! 


8.13: Command Recognizer 
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that only looks at RLO (but returns a full-word translation in RO); have 
GETCH, etc., clear RHO. What are the pros and cons of these changes? 
Are there other possibilities? What effect would these changes have on 
code already written? 

(d) Write a date recognizer that returns RHO = month; RLO = day; 
R1 = year. What should it be able to recognize? Can a cascade of TRAN 
tables be used to recognize month names? Roman numerals for months? 

(e) Write recognizers for numeric input. Recognize hex, decimal, octal 
or binary numbers with four separate recognizers that share common sub¬ 
routines. Each should be able to deal with an initial plus or minus sign. 

(f) Write a recognizer for time input. Accept four-digit military time or 
the usual time format (xx:xx AM, PM, M, N). Make sure that the usual 
format works without a leading zero for one-digit hours. 


!Line building routines 


CALL SLIN; Waits until last output operation done, then sets up OUTLIN 

CALL ELIN; Terminates line (with zero), then calls SAY to put out OUTLIN 

CALL ADDCHR; RLO = char; Adds char to OUTLIN 

CALL ADDSTR; R1 = adr of zero-terminated string; Adds it to OUTLIN. 

f 

SLIN: CALL TYWAIT 

IWait for prev op! 

PUSH @SR,R1 

ISaveRl! 

LDA Rl,OUTLIN; CALL EMPLIN 

Unitialize line! 

POP R1,@SR; RET 

!Restore Rl & exit! 

ELIN: PUSHL @SR,RR0 

!Save R0,R1! 

CLR RO; CALL ADDCHR 

!Terminate line! 

LDA Rl,OUTLIN; ADD R1,#LDAT 

!Point at text! 

CALL SAY 

!Put it out! 

POPL RR0,@SR; RET 

!Restore R0,R1; exit! 

ADDCHR: PUSH @SR,R1 

!SaveRl! 

LDA Rl,OUTLIN; CALL ADLINE 

!Add the character! 

POP R1,@SR; RET 

!Restore Rl; exit! 

ADDSTR: PUSH @SR,R1; PUSH @SR,R2 

!SaveRl,R2! 

LDR2,R1; LDA Rl,OUTLIN 

! Add the string! 

CALL ADLNST 


POP R2,@SR;POPRl,@SR 

!Restore R1,R2; exit! 

RET 



8.14: Some Line-Building Routines 
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Output Formatting 


While understanding what was typed is the main problem in dealing 
with input, the foremost output problem is formatting. There are two 
useful tools for this that we shall discuss here: cursor control and line 
building. We shall begin with line building, since it gives us a concete 
solution to the problem raised in Exercise 6: where does the output 
string reside while it is being output? The basic package for line 
building consists of a line (called OUTLIN) and some subroutines: 

SLIN: start the line (waits until the line is free). 

ELIN: end the line (calls SAY to put it out). 

ADDxxx: a variety of routines for adding things to the line, 
e.g., ADDSTR adds a zero-terminated string, ADDDEC 
adds the ASCII characters for the decimal representation 
of a given number, ADDCHR adds a single character, 
ADDDAT adds a date, and so on. 

Figure 8.14 shows the basic routines SLIN, ELIN and ADDCHR. All 
of the ADDxxx routines can probably be built using calls to 
ADDCHR, but this is inefficient. For this reason, the routine ADLNST 
was added to the line routines of Figures 8.8 and 8.9. The ADDSTR 
of Figure 8.14 uses ADLNST. ADLNST is presented in Figure 8.15 
along with EMPLIN, which is called by SLIN. 

EXERCISE 10: (a) Note that SLIN calls TYWAIT, even though there are 
Other things that TYOUT could be doing besides outputting from OUTLIN 
(echoing, for example). Is there a better way to assure that OUTLIN is 
free before initializing it? 

(b) Consider the following scheme: another state is added to TYOUT, 
corresponding to FLAG = BUFOUT. In this case, TYOUT will take its 
next output character from a ring buffer; if the ring is empty, then TYOUT 
enters a sleep state corresponding to FLAG = BSLEEP. Meanwhile, 
each time ELIN is called it transfers the contents of OUTLIN into the ring 
buffer. It does not return to the caller until OUTLIN is free, so SLIN 
never has to do a test. If ELIN finds FLAG = BSLEEP while adding 
characters, it sets FLAG = BUFOUT and does an SC #IOGO to get 
things going again. 

Work out the details of this scheme. 

(c) Write the routine ADDDAJ to add a date to OUTLIN. It should 
takes its arguments as follows: RHO = month (1 to 12); RLO = day (1 to 
31); R1 = year; R2 = format code. Among the options the caller should 
be able to specify are: 


I 
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Month: full name, abbreviation, number 
Year: 4 digits, last two digits 

Day: number, number followed by suffix (st, nd, rd, th) 

Order: mm/dd/yy; dd/mm/yy; month day year; day month year 

In addition, the program should be able to compute and supply in various 
formats the day of the week. 

(d) Now rewrite ADDDAT to take its date and format code from a 
table pointed to by Rl. Why is this better? Modify it again so the table 
contains the address of the date. Even better? 

Cursor Control 

The line building routines allow us to discuss cursor control. Most 
CRT displays allow some computer control of the cursor position. 
While there is not much standardization among manufacturers, in 
most cases the command to send the cursor to line L column C is a 
character sequence like 

C1,C2,B1 + L,B2 + C 

consisting of two control characters (ASCII codes 0 to IF) followed by 
the actual line and column numbers, possibly offset by constants. 
Figure 8.16 shows how to implement an ADDPOS routine to add an 
appropriate string to OUTLIN. CURPOS brackets ADDPOS between 
SLIN and ELIN calls. SCREEN shows how to display a screen load 
consisting of specified strings at specified row and column positions. 
SCREEN is an extremely useful way to do screen displays, since it is 
totally table driven. 


EXERCISE 11: (a) Write a version of SCREEN that uses ADDPOS and 
ADDSTR rather than CURPOS and SAY. How do you know when to do 
SLIN and ELIN calls? Does it matter how full OUTLIN gets before the 
ELIN? 

(b) Modify SCREEN so that it recognizes other special commands. For 
example, if the position word is - 2, let the entry consist of two more items: 
a position code followed by the address of an argument table for ADDDAT. 
If the ADDxxx routines are all written so that they take a single argument 
(possibly a table address) in Rl, then the correspondence of special position 
codes with ADDxxx routines can be embodied in a TRAN table; e.g., 

-2; ADDDAT; -3; ADDHEX; -4; ADDDEC;. . ., 

(c) Write a version of ASK that takes a screen position argument in RO 
and asks the question at the specified line and column. Should it have a 
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! Additional line routines 


CALLADLNST;R1 = adrofline 

R2 = adr of zero-terminated string. 

Returns C = 0 if whole string added to line 
C = 1 if part or none added. 

CALL EMPLIN; R1 = adrofline 
Sets line to “empty” 

I 

ADLNST: PUSHL @SR,RR2 !Save registers! 

PUSHL @SR,RR0 

LD R0,@R1; LD R3,R1(^LPTR) IGet size (n) & pointer! 

DEC RO; SUB R0,R3 !Space left (bytes)! 

JR LE,ALSER ! Not enough! 

ADDR1,#LDAT; ADDRLR3 
INC R1 

ALSLP: TESTB @R2; JR Z,ALSOK !More in string?! 

INC R3; LDIB @R1,@R2,R0 !Bump ptr; move byte! 

JR NOV,ALSLP 

TESTB @R2; JR Z,ALSOK !Full—OK if string empty! 

ALSER: SETFLG C; JR ALSOUT !No room; C = 0! 

ALSOK: RESFLG C ! All fit; C = 0! 

ALSOUT: POPL RR0,@SR; LD RI(^^^LPTR),R3 !Update pointer! 

POPL RR2,@SR; RET 

EMPLIN: PUSH @SR,R0; LD RO,#- 1 !Borrow RO! 

LD R1(#LPTR),R0 !Set line to empty! 

POP R0,@SR; RET !Return RO! 

8.15: Additions to the Line Routines 

facility for blanking some screen space for the answer? How do you handle 
situations like the one in Figure 8.12, where an incorrect response causes 
the program to repeat the question? 

(d) Most CRT’s have a screen-clearing command, usually implemented 
by sending one or two control characters to the output device. Write 
screen clearing routines ADDCLR and CLRSCR analogous to ADDPOS 
and CURPOS. Can you think of a better name than CLRSCR? 

Should the screen routine call a screen clearing routine before it be¬ 
gins? How about a special code in screen’s display table? 
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! Cursor positioning 


CALL ADDPOS; RHO = line(Oton-l) 

RLO = column (0 to m - 1) 

The character string Cl ,C2,B1 + line, B2 + column is added to OUTLIN 

CALL CURPOS; ROas for ADDPOS; the cursor is positioned. 

CALL SCREEN; R1 = adr of table of positions and string addresses 
Format of table: 

POSITION (as above); STRING ADR; POSITION; ADR;...; - 1 


ADDPOS: PUSHL @SR,RR0 
PUSH @SR,0O 

ADDS RH0,#B1; ADDB RL0,#B2 
PUSH @SR,R0 

LDB Rm,0Cl; LDB RL0,#C2 

PUSH @SR,R0 

LD R1,SR; CALL ADDSTR 

INC SRJ6 

POPL RR0,@SR 

RET 


ISave R0,R1! 

!Build string on stack! 


lAdd to OUTLIN! 
! Clear stack! 

!Restore R0,R1! 


CURPOS: CALL SLIN; CALL ADDPOS; CALL ELIN; RET 

SCREEN: PUSHL @SR,RR0; PUSH @SR,R2 !Save R0,R1,R2! 


LD R2,R1 

SCREL: CP @R2,0 - 1; JR EQ,SCREX 

LD R0,@R2; LD Rl,R2(//2) 

INC R2,04 

CALL CURPOS; CALL SAY 
JR SCREL 

SCREX: POP R2,@SR; POPL RR0,@SR 

RET 


! Table ptr to R2! 

!End of table?! 

!Get pos & string adr! 
!Inc ptr! 

!Move cursor; say string! 

!RestoreR0,Rl,R2! 


8.16: Cursor-Control Package 

As with input processing, our discussion of terminal output 
formatting has only scratched the surface. We have discussed some of 
the tools that will make most specific applications easier. 
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Bit Tables 


Another useful technique is the bit table (i.e., an array of one-bit 
flags packed together into bytes). When you have a large number of 
items and only one fact that you need to know about them (at least, as 
a first approximation), then a bit table provides a compact, efficient 
way to manage that information. For example, you may have a disk 
file of 10,000 blocks, some of which are free to be allocated and some 
of which are in use. A bit table can provide fast access to this 
information with minimal storage space (in this case, 1250 bytes). 

Figures 8.17, 8.18 and 8.19 present a bit table package. The routines 
BENT and BEXIT described in Figure 8.19 are similar to all the other 
context switching routines that we have discussed. The actual code is 
not presented. 


!Bit Table Package 

1. Bit manipulating & testing routines: BSET, BCLR, BTST. 

Call with R1 = adr of parameter table; Returns C = 1 if specified 
position is out of the range of the table, else C = 0. BSET and BCLR set or 
clear the bit; BTST sets Z if the bit is zero, else clears Z. 

2. Table Scanning Routines: INBIT, NXCLR, NXSET, PVCLR, PVSET, 
NXBIT, PVBIT. 

Call with R1 = adr of parameter table; for INBIT, call with RO = 
position to initialize to (0 to length -1 of table in bits); returns C = 1 if given 
position is out of range; otherwise C = 0 and the given position is made the 
“current” position. 

NXCLR scans forward from the current position to the next one with a 
zero bit and establishes it as the new “current” position; C = 1 if the end of 
the table is reached before another clear bit is found. 

NXSET scans forward for a set bit; PVCLR and PVSET are the analogous 
routines for scanning backward. NXBIT and PVBIT simply step. 

3. All of the above routines are called with R1 = address of a parameter table. 
The parameter table has the following format: 

First word: Address of the bit table 

! BTLEN = 2 !2nd word: table length in bits! 

BTPOS = 4 !3rd word: current table position! 


8.17: Calling Sequences and Definitions for Bit Table Package 
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IManipulating and Testing Routines! 


BSET: CALR BENT; JR C,BOUT 

SETB CURBY,BITN0; LDB ©POINT,CURBY 
BOUT: CALR BEXIT; RET 

BCLR: CALR BENT; JR C,BOUT 

RESB CURBY,BITNO; LDB ©POINT,CURBY; JR BOUT 

BTST: CALR BENT; JR C,BOUT 

BITB CURBY,BITNO; JR BOUT 

!Scanning Routines! 

INBIT: LD Rl(/i'BITPOS),RO; CALR BENT; JR BOUT 

NXSET: CALR NXBIT; JR C,NXER 

CALR BTST; RET C; RET NZ; JR NXSET 

NXCLR: CALR NXBIT; JR C,NXER 

CALR BTST; RET C; RET Z; JR NXCLR 

PVSET: CALR PVBIT; JR C,NXER 

CALR BTST; RET C; RET NZ; JR PVSET 

PVCLR: CALR PVBIT; JR C,NXER 

CALR BTST; RET C; RET Z; JR PVCLR 

NXBIT: LD RO,Rl(^i«ITPOS); INC RO; JR Z,NXER 

NXOK: LD R1(#BITPOS),RO; RESFLG C; RET 

NXER: SETFLG C; RET 

PVBIT: LD RO,R1(#BITPOS); DEC RO; JR NOV,NXOK 

JR MI,NXER; JR NXOK 

8.18: Bit Table Routines 

The routines BSET, BCLR and BTST are the obvious table main¬ 
tenance routines. The table-scanning routines provide a useful tool for 
sequential processing. 

EXERCISE 12: (a) Write BENT and BEXIT. 

(b) The approach taken to the table-scanning routines is very clear and 
straightforward, but it involves a lot of overhead. Compute the time used 
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Specification of Entry and Exit Routines for Bit Table Package 
Entry Routine: BENT 

Saves all registers to be used; if current position out of range, returns with 
C = l;elseC = 0 and sets up registers: 

CURBY: Byte register containing the actual byte of the bit table containing 
the current bit position. 

PARAM: Contains address of the parameter table. 

POINT: Contains the address from which the byte in CURBY was taken 
and to which the modified version (for BSET, BCLR) will be sent. 

BITNO: Word register containing bit number (0 to 7) of the current bit 
position in CURBY. 

RO: Scratch register. 

Exit Routine: BEXIT 

Restores all registers, preserves C,Z. 

8.19: Specification of Entry and Exit Routines for Bit Table 
Package 


by NXSET if the very next bit is set. Write a version of NXSET that elimi¬ 
nates overhead by doing things ad hoc; try to use the Z8000 block opera¬ 
tions if possible. Compare the time taken by your version and the version 
of Figure 8.18 as a function of how far away the next bit is. 

(c) Think of five applications for bit tables. How many of them can use 
the scanning routines? 

(d) What is the largest bit table that can be supported with this imple¬ 
mentation? How many bytes would it occupy? Explain the address arith¬ 
metic used in NXBIT and PVBIT and the error testing. 

The above examples give a good picture of how tools can be built 
for Z8000 programming applications. In the next chapter we shall 
show how an environment for appUcations programming can be created. 
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Chapter IX 

Advanced Programming Techniques 


This chapter will cover a number of useful techniques that apply 
more to complete systems than to specific application programs. 

Shareable Programs and Storage Management 

In most of the programs that we have presented in this book in¬ 
formation is manipulated in the ZSOOO’s general purpose registers. 
When a subroutine is called, it saves the contents of the registers it 
plans to use by pushing them onto the stack; when it is ready to exit it 
restores the register values from the stack. In fact, this presented some 
problems when we came to deal with the SAY routine, which gave the 
terminal I/O initiator program the address of a string to be output 
under interrupt. The string could not be stored on the stack by SAY, 
since SAY returns to the caller (thereby releasing its stack space) 
before the output is complete. 

We solved problems of this type by reference to buffers like INLINE 
and OUTLIN, but we never quite said where these buffers were to be. 

If you come from a minicomputer programming background, you 
may be wondering what difference it makes. Won’t any place in 
memory do? There are two answers to that: one relating to the typical 
microcomputer environment and one to the possibility of generalizing 
what we have done so far. 

The first answer is that we wish, insofar as it is possible, to store our 
programs in read-only memory (ROM); ROM is inexpensive, and it 
provides protection against inadvertent modification of programs. So 
buffers, tables, stacks and other modifiable storage must be carefully 
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separated from the program. This material is usually stored in 
read/write memory (called RAM—random access memory—for 
purely historical reasons). RAM is usually volatile, i.e., its contents 
are lost if power is turned off. Of course, programs can be stored in 
RAM also, and they usually are during development, since even ROM’s 
that can be modified using special systems and hardware are difficult 
to use for program development. But a ROM-based program is 
frequently a goal of microprocessor developments. 

The second answer is that programs that have no local storage of 
their own are potentially shareable, that is, they can be working with 
two different contexts simultaneously. The line routines of Figure 8.9 
provide an example of this: the routines LING, LDEC, LFETCH and 
LSTORE are called both by interrupt and by non-interrupt routines. 
For example, the routine GETFLD of Figure 8.11 calls GETC; GETC 
calls GETCH; GETCH calls LFETCH and LING. Assume that while 
the Z8000 is executing in LING (called through the above chain of 
routines from GETFLD), there is an interrupt from the terminal 
output device, and in the course of processing that interrupt TYOUT 
calls ADLINE, which calls LING. 

The original context that LING (called from GETFLD) was working 
on is saved on the stack by TYOUT’s call to TYENT. ADLINE’s call 
to LNENT sets up a new context that LING acts on when called. 
When TYOUT calls TYEXIT before its IRET, the original context is 
restored, and LING proceeds after the IRET as if no interrupt had 
occurred at all. The instructions of LING have been used in two 
different contexts simultaneously; that is, LING is shareable. 

If LING had not been shareable, e.g., if it stored its variables in 
memory locations with fixed addresses, then there would have had to 
have been one LING for the interrupt-time routines ADLINE and 
BACKUP and a different LING for GETCH and BACKCH. As it is 
now, any of the routines ADLINE, BACKUP, GETCH and BACKCH 
can be called by any program, and there is no need to duplicate them or 
any of their subroutines. 


Timesharing 

There is an even more important use for shareable routines: time¬ 
sharing. The separation of memory into shareable routines on the one 
hand, and the data they manipulate on the other, provides the basis 
for an easily implemented timesharing system. The basic idea is this: 
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in many applications, especially those involving interactions with 
operators at terminals, the computer can handle many times the load 
placed upon it by one operator. So instead of just one set of data for 
the shareable routines, there can be one set for each terminal. We shall 
come back to this presently, but first, since the basic idea depends 
upon being able to identify the entire set of data belonging to one 
terminal in such a way that we can switch rapidly from one set to 
another, let us look at how that data can be organized. 

Most of the routines we have looked at make extensive use of the 
stack for the saving and restoring of registers and could, if they needed 
more storage than the registers provide, use stack space for working 
area, so the stack seems to be a good starting point. In fact, in the 
routines we looked at in Chapter VI and Chapter VIII, the only non¬ 
stack storage was the buffers INRING, OUTLIN, and INLINE and 
the terminal I/O context block at CONBLK. 

It is usual in talking about timesharing to introduce a construct to 
simplify things: the user. This does not refer to any particular person. 
Instead it is a term associated with a set of facilities like a stack, a ring 
buffer and so on. This imaginary user is said to own the facilities in 
question—we speak of the user’s stack, the user’s ring buffer, etc. 

So what we are looking at now is how the user’s stack and the user’s 
INRING, OUTLIN, INLINE and CONBLK are to be organized. One 
possible arrangement, assuming that all of the items except the stack 
are of fixed size, is shown in Figure 9.1. This grouping into a block 
means that all of the other addresses could be computed from the top 
address at which OUTLIN ends. This address and the stack pointer 
would be sufficient to specify the user’s data area. 

But the scheme of Figure 9.1 is inflexible (all users must have the 
same sized buffers), and it does not take account of the fact that some 
information needs to be accessible at interrupt time (and so might be 
better grouped with other such items), while other parts are not needed 
at interrupt time. A scheme that answers these points is shown in 
Figure 9.2. With this scheme, the items can still be grouped together at 
the high end of the user’s data area, but they don’t have to be; they 
can be anywhere. 

For the examples given in the rest of this chapter we shall assume an 
arrangement like that of Figure 9.2. Notice that while the set of ad¬ 
dresses and the other similar items do not need to be adjacent to the 
user’s stack in memory, that area is a convenient place to put them, 
especially if we later decide to “swap” the user’s data out of memory 
onto a secondary storage device (e.g., a disk). This set of fixed loca- 
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Highest Memory Address 


OUTLIN 


INLINE 


INRING 


CONBLK 


Other Similar Items 


Start of Stack 


Current Top of Stack 


9.1: One Possible Arrangement of User Data 

tions at “the other end of the stack” is similar to what is called the 
heap in the PASCAL literature. 

Of course, now that there are many copies of CONBLK, INLINE, 
etc., the routines that use them will have to be revised. To do that, we 
need a way to refer to this user-specific data. A convenient way is to 
dedicate an address register, just as an address register is dedicated to 
being the stack register. So let the register HR point at the highest 
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Highest Memory Address 


Address of OUTLIN 


Address of INLINE 


Address of INRING 


Address of CONBLK 


Other Similar Items 


Start of Stack 


Current Top of Stack 


9.2: A Better Arrangement 

address of the user data area of Figure 9.2. Then the cell containing 
the address of OUTLIN can be referred to as @HR or HR(#0); the cell 
containing the address of INLINE is referred to as HR(# - 2); and so 
on. Notice that we are using the based addressing mode (only available 
with the LD instruction) so as to allow either segmented or non- 
segmented operation. For segmented operation, of course, the address 
register HR will be a register pair. 

Let us look at how various routines will have to be modified. Start 
with an easy one: ASK (Figure 8.10). Notice that there are two in¬ 
stances of the instruction 


LDARl,INLINE 


and one instance of 


LDARl, INRING 
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These can be replaced by 


LDR1,HR(#INLINF) 


and 


LDR1,HR(#INRINF) 


These assume the definitions (based on Figure 9.2): 

OUTLNF = 0; INLINF = -2; INRINF = -4; CONBKF = -6 

In other words, where the original ASK assumed one INLINE and 
one INRING and picked up their addresses with LDA, now there can 
be many, but the particular one we are interested in has its address in a 
fixed location relative to the current user’s data area. If HR is changed 
to point to another user’s area, then the same code in the ASK routine 
will result in setting up the new user’s INRING and INLINE. 

There is another problem with ASK and SAY: they pass the I/O 
address of the printer/screen to TYIO. This will also vary for each 
user, so in Figure 9.2 the section labeled “Other Similar Items” gets 
its first member. The definition 

TYOTPF = -8 
will let us replace the instruction 

LD SR(#POUTA),#TYOUTP 


by 


LD SR(#POUTA),HR(#TYOTPF) 


Incidentally, we shall probably need a similar item for the keyboard 
I/O address, but we do not use that here. Instead we specify the 
address of the input ring buffer (HR(#INRINF)). Somewhere in the 
system initialization the association between each ring buffer and its 
keyboard I/O address must be made. This information is recorded in 
the user’s CONBLK, since TYIN is the routine that uses it. 
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EXERCISE 1. Modify the routines GETC and BACKC of Figure 8.11 
along the lines used above. Make similar changes in the routines SLIN, 

ELIN, ADDCHR and ADDSTR of Figure 8.14. 

The next changes we must make are in the interrupt routines 
TYOUT and TYIN, but because of the way they are organized, the 
changes are in TYENT and TYEXIT. The problem here is to figure 
out which user’s CONBLK is to be used. It is not sufficient simply to 
refer to HR(#CONBKF), since once we introduce timesharing, the 
user whose terminal is interrupting may not be the user whose pro¬ 
gram is being interrupted. That is, we may need to change HR before 
HR(#CONBKF) gives us the correct address. 

The problem is that the register HR that defines the user’s data area, 
and so defines implicit arguments to the routines SAY, ASK, GETC, 
BACKC, etc., is not available at interrupt time. A different means 
must be found for going from the specific interrupt received to the 
appropriate context block. This in turn depends upon how the ter¬ 
minals use the Z8000 interrupt facilities. For concreteness, let us 
assume that there are eight terminals controlled by a multiplexing 
device that is connected to the first two vectored interrupt positions 
(see Figure 2.9); keyboard interrupts connect to the first vectored 
position, screen interrupts to the second. Let us also assume that the 
high-order byte of the “reason” pushed onto the stack for the inter¬ 
rupt contains a number from zero to seven specifying which terminal 
needs attention. 

Now assume that there is a table of eight addresses stored at location 
CONTBL. Each of these is the address of one of the context blocks, 
and the table is indexed by the terminal number. Assume that TYENT 
is to be called with the terminal number in RH2. This will entail changes 
to TYIN, TYOUT, and TYIO, which we shall deal with in a moment. 

TYENT can now be written. The context block must be expanded to 
include a register CONAD between lOUT and TYRT. (See Figure 

6.11.) The line 


LDM TYCON,CONBLK,#NTYCX - 1 


must be replaced by 


SRA R2,#8; LD CONAD,CONTBL(R2) 
LDMTYCON,@CONAD,#NTYCX - 2 
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where NTYCX has the new value 8. Neither CONAD nor TYRT is to 
be loaded from the context block. Then in TYEXIT the line 

LDM CONBLK,TYCON,#NTYCX 


is replaced by 


LDM ©CONAD,TYCON,#NTYCX 
The changes to TYOUT and TYIN involve adding the instruction 

EXR2,@SR 


in two places. 

Figure 9.3 shows a revised version of TYIO. Notice that the output 
I/O address and the ring address have been removed. These belong 
(conceptually) to the terminal, not to the user, so they become fixed 
entries in the context block, set at initialization of the system. Instead, 
TYIO uses the terminal number (referred to by HR(#TRMNOF)) to 
select the correct terminal context block. 

EXERCISE 2: (a) Why is R2 used to transmit the terminal number to 
TYENT? Why not RO or Rl? (Hint: see Figure 4.16 and Figure 9.3.) 

(b) Revise SAY and ASK to work with the new TYIO. What should be 
done to the routine TYWAIT of Figure 8.2? 

(c) Write out revised definitions for TYENT and TYEXIT; write out 
new versions of TYENT, TYEXIT, TYIN and TYOUT incorporating the 
above changes. 

Let us now summarize what we have done so far in trying to para¬ 
meterize the routines of Chapters VI and VIII to allow us to introduce 
timesharing: 

• We have given each user a data area with a set of parameters at 
one end in fixed positions relative to the base register HR and 
with a stack at the other end. Figure 9.4 shows a version incor¬ 
porating our latest changes. 

• We have built a table of terminal I/O context block addresses in¬ 
dexed by terminal number. The terminal number becomes part of 
the user’s data area, and terminal-specific items like the I/O ad¬ 
dresses and the input ring buffer address have been removed from 
the user area and have become fixed items in the terminal context 
table. (See Figure 9.5.) 
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!Terminal I/O Initiator (non-segmented) 

CALL TYIO; R1 = adr of parameter table 
Returns C = 0 if initiated 

C = 1 if command invalid 
I/O proceeds under interrupt. 


Parameter Table Format: 

Byte Address 

f 

PFLAG = 0 
PADR = 2 


For Input Request 

mNFVT 
! Address of LINE 


For Output Request 

^OUTPUT ! 

Address of output string ! 


LTYTAB = 4 


! Length of table! 


TYIO: 


TYOKX: 


CALR TYWAIT 

PUSH @SR,R2; LDB RH2,HR(i^^RMNOF) 

CALR TYENT 

LDB FLAG,R1(#PFLAG+1) 

LD PTR,R1(/«»ADR) 

CPB FLAG,^^fINPUT; JR EQ,TYOKX 

CPB FLAG,/^fOUTPUT; JR EQ,TYOKX 

LDB FLAG,i^^DONE 

SETFLG C; CALR TYEXIT 

POP R2,@SR; RET 

RESFLGC; CALR TYEXIT 

POP R2,@SR; SC #IOGO; RET 


! Wait for DONE! 

!Terminal number! 
!Set context! 

! Set FLAG & ! 

! Adr from Table ! 
! Check for ! 

! Valid cmd ! 

!Cancel cmd! 

!Error exit! 

!OK exit! 


9.3: Revised TYIO Initiator Routine 


• We have made some relatively small changes to TYENT, TYEXIT, 
TYOUT, TYIN and TYIO and extremely minor changes to some 
other routines. 

Timesharing enters in TYWAIT. That small routine at the bottom 
of Figure 8.2 is where all of the waiting is done, and the basic idea of 
timesharing is that the computer should run a user who has something 
to do as soon as the current one needs to wait. Figure 9.6 shows the 
version of TYWAIT that implements timesharing. Because of the way 
we have organized everything, TYWAIT is still very simple. All it has 
to remember for each user is the contents of the 16 general purpose 
registers. Fifteen of these are stored in the user’s data area, and the 
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Definitions of item offsets from HR: 


INLINF = 0 

OUTLNF = -2 
TRAANOF = -4 
USRNOF = -5 


Address of Input Line Buffer 
Address of Output Line Buffer 
Terminal Number 
User Number 


9.4: User Data Arrangement 


sixteenth, the address of the data area, is saved in a table indexed by 
user number. Then, starting at the user number after the current user’s 
number, TYWAIT cycles through the users one at a time, checking the 
context block for each user’s terminal until one is found with FLAG 
= DONE. That user is ready to run. 

Starting up a user after a wait is simple: it consists of undoing what 
was done at the start of TYWAIT. The SR value is restored by re¬ 
ferring to HR(#SRF), then the other 14 registers are reloaded from the 
stack. Finally, since the chain of subroutine return addresses is still 
on the user’s stack, the RET at the end works just as if no one else had 
been allowed to run during the wait. Figure 9.7 shows how everything 
is saved. 
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0 


Address of User 0 
Context Block 


Address of User 1 
Context Block 




Address of User 7 
Context Block 


CONTBL 


FLAG 


CHAR 


PTR 


RING* 


LINE 


lOIN* 


lOUT* 


CONAD 


TYRT 


Context Block for a Single Terminal 
*Set at system initialization. 


9.5: Terminal Context Blocks 


EXERCISE 3: (a) The one piece of status that is not saved by the above is 
the flag/control word. Should it be saved? Should part of it be saved? If 
you wished to save it, how would you do so? (Hint: remember LDCTL 
and LDCTLB.) 

(b) What if you wanted to allow users to wait for other conditions be¬ 
sides FLAG = DONE for their terminals; e.g., a user may wish to wait 
until five seconds have elapsed before clearing an error message from the 
screen. What kind of information would TYWAIT need? Where should 
it be kept? 

(c) Notice that the values in HRTB never change. Should it be done dif¬ 
ferently? What if there were more users than could have data areas in 
memory at once? How could you keep track of which ones were in mem¬ 
ory and which ones were not? How could you arrange for TYWAIT to 
have enough information to be able to test whether a user was ready to 
run without looking in the user’s data area (which may not be in memory)? 

(d) What happens if a user calls TYWAIT when its terminal context 
block already has FLAG = DONE? How could this be used? 
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! Rudimentary Scheduler/Swapper 


CALL TYWAIT; return after: 


1. 

Every other user is checked; and 


2. 

\ 

Your terminal’s context block has FLAG 

= DONE 

NWTRG 

= 14 ! Assume non-segmented operation! 

WTRGB 

= 2*NWTRG !Bytes of stack storage needed for registers! 

!Uses the table HRTB, indexed by user number, to store HR value for each user! 

TYWAIT: 

DEC SR,mTRGB 

!Saveregs on stack! 


LDM @SR,RO,#NWTRG 



LD HR(#SRF),SR 

!Save stack pointer! 


LDB RLl,HRWSRNOF) 

!Get current user #! 


CLRB RHl; LD HRTB(R1),HR 

!Save user’s HR! 

WTLP: 

INC R1 

!Next user! 


CPR1,/^^MXUSER; JRLT,WT1 

! (modMXUSER)! 


SUB Rl,/WVfXUSER 


WTl: 

LD HR,HRTB(R1) 

!Get user’s HR! 


LD RL2,HR(;iTRMNOF); CLRB RHl 

!Then user’s terminal! 


LD R2,CONTBL(R2) 

!FLAG = DONE?! 


CPB @R2,#DONE 



JR NE,WTLP 

! No—can’t run! 


LD SR,HR(#SRF) 

! Yes—restore SR! 


LDM RO,@SR,#NWTRG 

! and registers! 


INC SR,#WTRGB 



RET 

!Return at Last! 


9.6: A Simple Round Robin Timesharing Swapper 

Stack Management 

We have seen how important the stack is to all of the programs and 
system designs we have been doing, but the use of stacks also presents 
problems: 

• The return addresses are always getting in the way; e.g., look at 
TYENT and TYEXIT. 

• One consequence of this is that it is extremely difficult to pass 
arguments between routines by using the stack. 

• Every subroutine must diligently control its stack use so that it 
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USER DATA AREA 


REGISTERS 



STATE OF USER AREA AND REGISTERS WHEN TYWAIT IS CALLED 


USER DATA AREA 




9.7: Saving the Status of a User Waiting for I/O 















removes exactly as much as it has added; otherwise its RET will 
fail. 

One solution to these problems lies in the use of separate stacks: the 
stack used by the processor for subroutine calls and returns and another 
stack, managed by the software, for temporary storage and argument 
passing. 

Figure 9.8 shows how such a mechanism might work. As a subroutine 
is called, its storage stack register is saved on the call stack along 
with the return address; then on exit the storage stack register is re¬ 
stored automatically, so the routine X does not need to keep track of 
and remove the stack storage it used. With this mechanism the passing 
of arguments on the stack becomes straightforward: the saved value 
of the storage stack pointer can be altered, so the new value is restored 
on return. Figure 9.9 shows how this could work. 

Notice that we have kept the register name SR for the storage stack 
and introduced the new name SP for the call stack. This means that 
SP must be R15 for non-segmented operation or RR14 for segmented 
operation. SR can be any address register we choose. For concrete¬ 
ness, let us assume that HR, SR and SP are the last three address regi¬ 
sters: either R13, R14, R15 for non-segmented operation or RRIO, 
RR12, RR14 for segmented operation. 

We have not yet said how to make all of this happen. Of course, 
each routine could push SR onto the SP stack on entry and pop it back 
before exit—this is a little bit shaky and error-prone. A somewhat bet¬ 
ter approach, with some desirable side-effects, is provided by requiring 
each subroutine, on entry, to call a system entry routine that does both 
the saving and the restoring of SR. The entry routine then calls the 
body of the subroutine, so the original routine’s RET returns through 
the entry routine, which then adjusts the stacks and does the return to 
the caller of the original subroutine. Figure 9.10 illustrates this. Only 
one level is shown, but this can be repeated to any depth. Figure 9.11 
shows the actual code. 

EXERCISE 4: (a) What does the SP stack look like if there are several 
levels of subroutine calls? 

(b) What does SENTRY do to C, Z, S, V, D, H? How can that be used? 

(c) Write SENTRY and SRPASS for segmented operation. Can address 
register names and stack positions be defined symbolically so that the 
segmented and non-segmented versions have the same source code except 
for the values assigned in the definitions? 

(d) Compute the overhead in time (cycles) associated with using SEN¬ 
TRY. It takes a great many instructions for a fairly simple task; can it be 
improved? 


260 PROGRAMMING THE Z8000 



















































Main Program 


Subroutine X 


System Entry Routine 



The dark line indicates the flow of control; that is, the order 
instructions. 


Adjust stacks 

CALL Body of Caller 
Adjust stacks 

Return to main 
of execution of 


9.10: Flow of Control Using System Entry Program 


! System Entry Routine 

CALL SENTRY 

This should be the first instruction of each subroutine; SENTRY will insure 
that the value of SR on exit from the subroutine is the same as it was on entry; 
it does this by taking control and calling the body of the subroutine as if it were 
a subroutine of SENTRY. 

SENTRY uses the SP stack to remember the SR value that it will restore; it 
enters the body of the calling subroutine with the address of its exit code on top 
of the SP stack and with the saved SR as the next item down. A change to this 
second item can allow SENTRY to restore a different SR value from the one it 
was called with. This is accomplished by a call to SRPASS, which in effect 
executes a LD SP(#2),SR. 


In a segmented version the code of SRPASS and SENTRY would be almost 
completely different. 


On exit, SENTRY does a TEST RO, so passing of results back in RO is facilitated. 
SENTRY leaves C unaffected, so it can be used for error status. 


SENTRY: 


SENX: 


EX SR,@SP 

PUSH @SP,R0; LDA R0,SENX 
EX R0,@SP 

PUSH @SP,SR; LD SR,SP(^4) 
RET 

POP SR,@SP; TEST RO; RET 


ISave SR, hold subr adr in SR! 
IPush SENX adr onto SP! 

!Push subr adr, restore SR! 

!Phony RET calls subr body! 

!Restore pre-call SR, do real RET! 


SRPASS: LD SP(^^^4),SR; RET 


9.n: System Entry Routine for Stack Management 
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EXERCISE 5: If the stack management scheme described here were used 
in conjunction with the timesharing facility previously discussed, how 
would TYWAIT have to be changed? Where would the user’s SP stack 
be stored? Would there be any advantage to having all users share a com¬ 
mon SP stack? If so, what would need to be removed from the SP stack 
by TYWAIT and saved in the user area? 


An SC Dispatch Mechanism 

We have talked about the SC instruction, and in Chapter VIII we 
used SC in the initiator routine TYIO to simulate a terminal interrupt. 
The SC has two main purposes: 

• To provide a way for “normal” mode programs to call on “sys¬ 
tem” mode programs 

• To provide one-word calls on frequently used routines. 

When an SC instruction is executed, a trap occurs. In Chapter II we 
discussed the mechanism by which traps are handled: the PC, FCW 
and the instruction are pushed onto the stack, and a transfer is made 
to a processing program by setting the PC and FCW to values stored 
in the program status area (see Figures 2.8, 2.9). 

SC is intended to be used for up to 256 different system routines. 
The low-order byte of the instruction contains a value from 0 to 255. 
Since the instruction is on the stack, the processing routine can use 
that byte as an index to a table of system routine addresses. At this 
point some design decisions must be made: 

• Should the system routines simply be transferred to, or should 
they be called? In the first case, each of them must do an IRET; 
in the second case the SC handler does the IRET, so the system 
routines are just subroutines that can also be called directly. 

• Should the SC handler save any registers (and restore them if the 
system routines are subroutines)? 

• Should the SC handler set up any registers (e.g., the address of 
the return, so arguments could be passed by placing them in the 
memory location following the SC, or so the routines could return 
to, say, the first, second or third location after the SC, depending 
upon some condition)? 

• How should the SC routines interact with the SENTRY/SRPASS 
mechanism? 

We cannot answer all of these questions without a context, since the 
answers may differ for different applications. Figure 9.12 shows an 
absolutely minimal SC handler; all it does is pass control to the ap¬ 
propriate routine. Notice how the handler transfers control to the 
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appropriate system routine by placing the system routine’s address on 
the SP stack and doing a RET. This is a convenient way of going some¬ 
where without storing the address in a register or in a “permanent” 
memory location. Also notice that we used both stacks, taking advan¬ 
tage of our stack management scheme. Of course the same thing could 
be done with just one stack (using the EX instruction to restore R1 and 
put the system routine address on the stack), but the code is a little 
longer. 

EXERCISE 6: (a) Modify SCHAND so that it uses calls instead of trans¬ 
fers; you will have to use a trick similar to the one SENTRY uses if you 
wish to arrive at the system routine with the registers unmodified. 

(b) Modify SCHAND so that it calls the system routines with RO and 
R1 saved on the SR stack and their contents replaced by the FCW and 
PC values from the SP stack. When the system routine returns, SCHAND 
should take the FCW and PC values, possibly modified by the system 
routine and use them to update the copies saved on the SP stack by the 
SC trap. Then it should restore RO and R1 from the SR stack (where they 
may have been modified by the system routine) and do the IRET. 

What are the pros and cons of this approach? 

(c) Write a version of SCHAND that saves all of the registers except 
HR, SR, SP on the SR stack, calls the system routine, then restores them 
all before doing the IRET. 

(d) Write a version of SCHAND that has two tables: the system routine 
address table and a table of one-byte option codes for the way that 
SCHAND should interact with the system routines. The option code for 
a system routine should be interpreted as follows: 

Bit 0: Clear to transfer (routine does IRET). 

Set to call (SCHAND does IRET). 

Bit I: Set to save the registers (except HR, SR, SP) on the SR stack (and 
to restore them before IRET if Call option). 

Clear not to save registers. 

Bit 2: Set to put FCW and PC into RO, R1. 

Clear not to do so. 

Bit 3: Set to update FCW and PC with values passed back by the system 
routine in RO, Rl. 

Clear not to do so. 

All of these options are intended to be independently specifiable. Are there 
any contradictory combinations? 

(e) All of the above examples are for non-segmented operation. How 
do they differ running in a Z8002 or in a non-segmented Z8001? (See 
Figure 2.7.) What would they be like in a segmented Z8001? Can all of 
the differences be localized in SCHAND? 

The variations in the preceding exercise can be expanded indefinite¬ 
ly. There is no ideal way to use this facility. 
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!Processing code for SC trap (non-segmented)! 

SCHAND: PUSH @SR,R1 

ISave R1 on SR stack! 

LD R1,@SP; CURB RHl 

Ilndex of routine! 

PUSH @SP,SCTAB(R1) 

!Put routine adr on SP stack! 

POP R1,@SR; RET 

!Restore R1 and to to routine! 


9.12: Minimal SC Handler 


In Chapter VIII we used the command 

SC #IOGO 

to accomplish a simulated terminal output interrupt. This requires a 
version of SCHAND that does not call the system routines (or at least 
has an option to transfer directly); the version of Figure 9.12 can be 
used for this purpose. 

The way this would work in our pre-timesharing environment was 
very simple: lOGO is simply the symbolic name for an index between 
0 and 255; the corresponding entry in the SCTAB of Figure 9.12 would 
be the address TYOUT. In the timesharing version TYOUT assumes 
that the “reason” contains the terminal number in its high byte. So 
instead of going directly to TYOUT, the entry corresponding to lOGO 
should take us to a routine TYSIM that looks like this: 

!Put terminal number into “reason”! 

TYSIM: EXR0,@SP 

LDB RHO,HR(#TRMNOF) 

EX R0,@SP 
JR TYOUT 

TYSIM can assume that HR is set for the right user, since the SC rou¬ 
tines are not interrupt time routines like TYOUT and TYIN, which 
cannot assume a correct setting of HR. 

System Initialization 

Often the last part of a system to be written is the “initialization;” 
this is because you do not know what the initialization has to prepare 
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the way for until the rest of the program has been written. 

What has been presented is not really a system of programs; it is a 
collection of related techniques. But forgetting that for a moment, let 
us look at what sort of initialization our system requires as it comes up 
from a cold start. The very first question we have to answer is: “Where 
does the CPU begin executing, i.e., what are its initial PC and FCW 
settings?” 

The answer to that question is that the CPU takes its initial status 
from location 2 of instruction memory, where it is stored in stack for¬ 
mat (see Figure 2.7). For a Z8001 that uses an MMU for address trans¬ 
lation there is the added complication of seeing that this initial fetch 
of FCW and PC from memory is carried out properly. The MMU hard¬ 
ware takes care of this. It can be so arranged that the MMU that nor¬ 
mally translates “system mode, segment zero” (or any other MMU for 
that matter) is placed by the RESET signal into the state in which ad¬ 
dresses are passed untranslated to the memory. 

This initial CPU status allows us to specify (see Figure 2.6): 

• segmented or non-segmented operation 

• system or normal mode 

• vectored interrupts disabled or enabled 

• non-vectored interrupts disabled or enabled. 

Since our initialization will require execution of privileged instructions, 
we must specify system mode. Since the program status address pointer 
is not yet set, we must specify interrupts disabled. 

The PC set by this RESET process points us to our startup code. 
The first thing this code must do is set the program status address reg¬ 
ister (see Figure 2.9). The program status area must be in a known block 
of physical instruction memory, since initialization of MMU’s has not 
yet begun. (We do not want to initialize the MMU’s before setting the 
program status address register, since we want the segment trap pro¬ 
cessing to be set up before we make any use of memory management.) 
The program status area contents can be assembled as part of the pro¬ 
gram. This is a great advantage that the ZSCKX) has over machines like 
the PDP-11 that use fixed memory locations for trap processing. In 
such machines the interrupt/trap vectors must be set up by explicit 
code, since they would otherwise interfere with the operation of the 
loader. In the Z8000, only the program status address register must 
be set explicitly. 

Next the hardware stack register (R15 or RR14) must be set; both 
the stack register and the program status address register must be set 
before any traps or interrupts can be processed. The stack register must 
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be set to a known address in physical stack memory, since the MMU’s 
are still only passing addresses untranslated. 

Let us look at how the program status area is to be set up. Figure 
9.13 shows a program status area for a system with features such as we 
have discussed. Following the outline of Figure 2.9 (non-segmented 
version) an (FCW, PC) pair is set up for each trap or interrupt type. 
The initial definitions are to facilitate symbolic settings of FCW for 
the various processing routines. No settings of the FLAGS bits are 
made (i.e., they are all set to zero), but they could be used to pass in¬ 
formation to a common trap handler. For example, if unimplemented 
instruction and system call were handled by one routine (instead of the 
separate routines UNHAND and SCHAND), then, say, the C bit 
would be set in the unimplemented instruction FCW and clear in the 
system call FCW. This could be accomplished using a definition 

CBIT = BIT7 


and writing 


SYSPRO + ENABLE -h CBIT 

for the unimplemented instruction FCW setting. 

Of the handling routines specified in the PSA of Figure 9.13, SCHAND, 
TYIN and TYOUT are familiar to us. The others would have to be 
provided. PIHAND, SEHAND and UNKNOWN are handlers for 
error conditions: execution of a privileged instruction in normal mode, 
a segment error reported by the MMU and a vectored interrupt with 
an unassigned device ID. 

The routine UNHAND can be an error routine, or it can be used as 
outlined in Chapter IV—as a call facility for up to 6 more sets of sys¬ 
tem routines. This could remove some of the complication of the various 
SCHAND design options; different sets of routines could be provided 
with different handling strategies. 

One possible assignment for the final two interrupts is: 

NMHAND: “odd-word address” trap 

NVHAND: power fail 

That is, NMHAND could report attempts to fetch a word or long- 
word of data from an odd address. This requires an externally imple- 
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! Program Status Area 

This table defines the CPU status to be set prior to processing any of the inter¬ 
rupts or traps that the ZSOOO can respond to. This is a non-segmented version 
(usable only on the Z8002); there is a one-word FCW and a one-word PC for 
each trap or interrupt. 

f 

SYSBIT = BIT14 
SEGBIT = 0 

SYSPRO = SYSBIT + SEGBIT 


!System/normal bit! 

!Non-segmented version—never set seg bit! 
!Setting for “system” programs! 


EVIBIT = BIT12 

ENVBIT = BITll 

ENABLE = EVIBIT-H ENVBIT 


!Enable vectored interrupts! 

!Enable non-vectored interrupts! 
!Enables both kinds! 


PSA: 0;0 

SYSPRO + ENABLE; UNHAND 
SYSPRO + ENABLE; PIHAND 
SYSPRO + ENABLE; SCHAND 
SYSPRO; SEHAND 
SYSPRO; NMHAND 
SYSPRO; NVHAND 
SYSPRO + ENVBIT 
TYIN 
TYOUT 
UNKNOWN 


UNKNOWN 


! Unused! 

!Unimplemented instruction! 

!Privileged instruction! 

!System call! 

!Segment error—stop interrupts! 
!NMI—turn off the others! 
!NVI—turn off the others! 

!VI—allow non-vectored! 

! 0: Keyboard input! 

! 1: Printer/Screen output! 

! 2: Unknown device! 

! • ! 

! • ! 

! • ! 

! 255: Unknown device! 


9.13: Program Status Area 


merited interrupt facility such as suggested in Chapter IV. Figure 9.14 
shows the outline of such a facility. 

We shall not go into further detail on the interrupt handlers, since 
their behavior depends upon details of their intended application. 

Figure 9.15 shows the entire initialization sequence needed to go from 
a cold start to a running timesharing system of the type described earlier 
in this chapter. The definitions RAM = %4(XX) and RATE = 60*BIT9 
represent purely arbitrary settings of parameters that will vary from 


ADVANCED PROGRAMMING TECHNIQUES 269 



NMIACK 



(1) SI 3 is set for memory references, clear otherwise (see Figure 2.12). 

( 2 ) ADo is set for odd addresses. 

(3) B/W is clear for word references. 

This circuit will not catch attempts by the program to transfer to odd addresses, 
since the PC does not latch bit zero. An attempt to transfer to an odd address 
results in a transfer to the next lower even address. 

Special Note: In CPU's manufactured before January 1980, the B/W status may 
not be valid during the first word of instruction fetches (ST3-ST0 value of Cu—see 
Figure 2.12). In that case, this circuit might trap some instruction fetches that were 
actually valid. 


9.14: An Externally Implemented "Odd Word Address" Trap 


system to system. The expression 60*BIT9 defines a value of 60 in a 
field ending at bit 9 (the symbol BIT9 is assumed to be defined else¬ 
where as 512, i.e., 2^). Setting the REFRESH register to the value 
RE -f RATE enables the generation of refresh cycles and sets the rate 
at 60, i.e., one every 15 microseconds with a 4 MHz clock. 

The line $ABS 2 is intended as an instruction to the assembler and 
the loader that this code must begin at absolute physical memory loca¬ 
tion 2. The actual pseudo-op used may vary from assembler to assembler. 
The two words following are the CPU status to be set up after a RESET; 
the symbol SYSPRO is from Figure 9.13. 

The three subroutine calls to INITMMU, INITERM and INITSS 
provide for initialization of all of the facilities that we have discussed. 
We shall not discuss INITMMU, but we shall give outlines of what 
INITERM and INITSS must do. 
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! Sequence of instructions executed at cold start (non-segmented)! 

RAM = %4000 

!First location of RAM! 

SYSTACK = RAM + 256 

Ilnitial stack location! 

RE = BIT15 

!Enable bit and RATE ! 

RATE = 60*BIT9 

! for REFRESH register! 

$ABS 2 


SYSPRO; START 


START: LDA RO.PSA 

!Set PSAP! 

LDCTL PSAP, RO 


LDA SP,SYSTACK; El NVI 

!Set stack reg; enable power fail! 

LD R0,mE + RATE 

!Start REFRESH register! 

LDCTL REFRESH,RO 


CALR INITMMU 

!Initialize MMU’s (seg. only)! 

CALR INITERM; El VI 

!Set up context blocks & rings! 

CALR INITSS 

!Build user data areas! 

CALL TYWAIT 

! Start timesharing—never come 


back! 


9.15: System Initialization code 

INITERM provides initialization for the terminals: 

• The table of context block addresses at CONTBL must be set up 
(Figure 9.5). 

• Each of the context blocks must be initialized: the I/O addresses 
lOIN and lOUT and the input buffer address RING must be 
determined and set; the FLAG should be given an initial value of 
DONE. 

• Each of the ring buffers must be initialized, i.e., its length set, 
its contents cleared and its pointers set to a common value be¬ 
tween 0 and n- 1 (Figures 8.3, 8.5). (Another ring routine should 
be added to Figure 8.4 for this purpose.) 

• It might be desirable to send an initializing character to each printer/ 
screen. In that case FLAG could be set to OUTPUT and PTR 
could be set to the address of a NUL. Then any character (prefer¬ 
ably non-printing) could be sent to each terminal, and as each 
became ready and interrupted, TYOUT would set its FLAG to 
DONE (Figure 6.12). 

The I/O addresses and input buffer addresses and lengths could be 
assembled as part of the program into a table used by INITERM, or 
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the table could contain only I/O addresses and buffer lengths, and the 
buffer locations could be allocated at initialization time. 

INITSS provides initialization for our timesharing system. The de¬ 
tails of this depend upon whether or not we use the two-stack scheme 
described in the section on Stack Management. Since our earlier dis¬ 
cussion of timesharing was for the one-stack case, we shall describe 
the one-stack version of initialization: 

• The table of user data addresses at HRTB must be set up (Figure 9.7). 

• Each of the user data areas (Figure 9.4) must be initialized: a user 
number between 0 and MXUSER -1 (see Figure 9.6) and a terminal 
number must be assigned; the addresses of the input and output 
line buffers must be determined and set; an initial stack register 
value must be set (using HR(#SRF), not shown in Figure 9.4—see 
Figure 9.6). 

• Each of the line buffers must be initialized, i.e., its length set (Fig¬ 
ure 8.8). (Another line routine should be added to Figure 8.9 for 
this purpose.) 

• A “dummy” return address (actually the desired starting address 
for each user) should be placed on the user’s stack, as if the location 
before the starting address had contained a call to TYWAIT. 

• Since the call to INITSS is followed by a call to TYWAIT, INITSS 
must give itself a dummy user data area and HR value for TYWAIT 
to work with. If INITSS gives itself the number MXUSER and if 
HRTB is extended by one word to have a slot indexed by MXUSER, 
then the round robin sequence will be: 

MXUSER, 1,2,... ,MXUSER -1,0,1,... ,MXUSER -1,0,1,... 

In other words, INITSS borrows user zero’s first turn to set things up 
and then never runs again. 

As with the keyboard input ring buffers, the user data areas and 
input and output line buffers can be pre-allocated at program assembly 
time, or they can be allocated at initialization time. 

EXERCISE 7: (a) Assume that a clock is attached to vectored interrupt 
index 2, so that an interrupt occurs every 100 ms. Write an interrupt hand¬ 
ler for this clock and link it into the PSA shown in Figure 9.13. Your 
handler should update a time-of-day stored as hours, minutes, seconds, 
tenths. It should update the tenths, carry over to seconds, minutes and 
hours if necessary and reset to zeroes at midnight. It should also set a “next 
day’’ flag at midnight to be used by a separate date maintaining routine. 

(b) Using ASK and the other routines of Chapter VIII, write a section 
of code that interacts with the user to allow the time-of-day to be set. 
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EXERCISE 8: (a) Suppose that we wished to run all of our programs in 
normal mode, except for the interrupt and trap handlers and all routines 
called by SCHAND. How would our initialization change? Would we 
need to use the NSP control register? Could we avoid having a dummy 
user area for the INITSS routine by using an LDPS instruction to take 
us into the middle of TYWAIT and simultaneously change to normal 
mode? 

(b) Write INITERM and INITSS assuming assembled tables defining 
the memory allocations. 

(c) Devise a memory allocation for the two-stack scheme and alter 
TYWAIT and INITSS accordingly. What else needs to change? 

(d) Provide segmented versions of the routines of this chapter. 
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Chapter X 

The Program Development Environment 


In the preceding chapters of this book we have covered the facts 
about the Z8000 that programmers need to know. We have illustrated 
the process of going from a written algorithm to a written program; 
we have seen what Z8000 programs for various applications look like; 
and we have used and discussed the important design principles of 
modern software engineering. These things are common to all Z8(X)0 
programming. In this chapter we shall discuss the variable part: the 
particular collection of hardware and software tools for program 
development that each programmer must work with—the program 
development environment. 

The most fundamental development tools are: a text editor, an 
assembler/loader and a debugging facility. A text editor, or word 
processor as it has recently come to be called, is a program for exam¬ 
ining and updating a block of text kept in machine readable form. 
Examining and updating is sometimes called “maintaining,” and a 
block of text kept in machine readable form is called a text file; so a 
text editor is a program for maintaining text files. Printing of text files 
is also sometimes considered an editor function, but this is actually a 
distinct function. A “runoff” program for printing text files in 
various formats can serve many modules of the development system— 
not just the editor. 

The principal use of a text editor in a program development envi¬ 
ronment is to prepare and maintain the source files. These are text 
files containing programs. For example, all of the text of Figures 6.11, 
6.12, 6.13, 6.14 and 8.2 might together make up the source file for a 
terminal I/O package. 

The assembler is the program that translates source files into actual 
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machine code, that is, it specifies the setting of every bit of every byte 
of the portion of memory allocated to the program being assembled. 
The assembler and editor must work with a common source file 
format. In other words, the editor must prepare files in the same 
format as the one in which the assembler expects its source input to be. 
On the other end, the machine code output by the assembler, called the 
object file, must be in a format recognized by the loader. The loader is 
the program that translates assembler output into the actual program 
that resides in the computer’s memory. This can be the simple process 
of loading the assembler’s output, byte-for-byte, into the memory, or 
it can be a merging of assembler output files and an establishing of 
linkages among them. 

The functions of the assembler and the loader are not distinct. They 
are two steps in one process, the translation of the programmer’s 
source code into a corresponding set of machine instructions, but the 
separation provides modularity in two ways: 

• The assembler output (object file) can be prepared at one time 
(and on one configuration of hardware) and loaded at some later 
time (and on a different, possibly smaller or larger, configuration) 

• The machine code can be built from several object files, thus 
allowing logically separate parts of a large program to be edited 
and assembled separately and also allowing programmers to aug¬ 
ment their programs with selections from “program libraries” 
of utility subroutines 

A debugging facility, as the name suggests, is a tool for removing 
errors from programs. In its simplest form it is a program for finding 
out the contents of selected registers and data memory locations at 
various points in the operation of the program being “debugged.” In 
its most sophisticated form it is a hardware/software system that 
monitors the states of the CPU and many of its associated busses and 
peripheral devices. It saves these states for a range of time before and 
after specified “triggering” events. 

A debug facility can be entirety independent of the assembler/load¬ 
er and its output. In this case all addresses and contents are regarded 
as binary or hexadecimal numbers, and all interpretation is left to the 
programmer. Often this is all the programmer will have to work with, 
but a better debug facility will be able to assemble or disassemble 
instructions using the assembler mnemonics and syntax and even the 
specific symbols defined in the source files for the program being 
examined. 

In the following sections we shall discuss in greater detail the 
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features and options of these fundamental program development 
tools. 

Text Editors 

Generally speaking, text editors have little to do with the computer 
for which source files are being generated. Instead, popular editors 
tend to migrate from one computer system to another. For example, 
the editor TECO, first developed for the DEC PDF-10, is now 
available for use with many other computers. There is little doubt that 
there will soon be a TECO available for use on Z8000 systems. Also, 
the popular “word processing” systems that many clerical personnel 
have already been trained to operate should soon come into 
widespread use in source file preparation. Meanwhile, the editors 
most likely to be available for use with the Z8000 will be adaptations 
of those previously developed or adapted for use with the Z80, 8080 or 
other popular microprocessors. This is especially true of editors on 
Z8000 development systems running on Z80-based microcomputers. 

The basic operations of an editor are: 

• The creation of new text 

• The deletion of old text 

• The rearrangement of existing text 

• The systematic or ad hoc replacement of one piece of text by another 

• The management of various files and storage media containing 
the text being operated upon. 

There are three main features that distinguish editors from one another: 

• Whether they regard the text they work with as strings of text or as 
collections of lines 

• The power and flexibility of their command specification mechanism 

• Whether they allow skipping from place to place in the text file at 
will or whether they require a “pass” over the file from front to 
back, usually a “page” at a time. 

Much can be said in general about editors, but this is of little direct 
use to the Z8000 programmer. The one feature that is common to 
all editors is that their commands seem difficult to learn at first but 
soon become second nature to the frequent user. 

Assemblers 

Unlike an editor, an assembler is closely tied to the details of the 
particular computer for which it is provided. Its purpose is to produce 
machine code from source files consisting of instructions built from 
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manufacturer-specified mnemonics and programmer-defined symbols 
for constants and memory addresses. Every computer manufacturer 
provides at least one assembler for each of its computers, and 
additional assemblers are usually available from outside vendors. The 
variations on the basic theme stated above are: 

• Macros 

• Conditional assembly 

• Local symbols 

• Control structures 

• Relocatable code 

• Support for text strings 

• Arithmetic and logical operations on symbols. 
Throughout this book we have presented programs that implicitly 

assumed the existence of an assembler; of the features named above, 
only the final two were used in any of our programs. 

For example, in Figure 6.13 

ESCS: BYTES (‘$’, V’, TRM) 

assumes an extremely minimal support for text strings. Most 
assemblers will allow something like 

ESCS: ASCII “$/” 

with the optional inclusion of a string-terminating character (TRM 
above) specifiable in some way. 

We made use of arithmetic operations on symbols with expressions 
like 


SYSTACK = RAM-h 256 
RATE = 60*BIT9 

from Figure 9.15. Most assemblers support such elementary expres¬ 
sions, but expressions involving symbols for registers (e.g., see Figure 
6.11) are likely to be restricted in some assemblers. 

In Chapter III we alluded to the problems that make local symbols 
desirable. With most assemblers, any symbol can be referred to at any 
other point in the same source file, but some assemblers provide a 
means for restricting use of a given symbol to a specified portion of 
the source file, e.g., to the subroutine in which it is defined. 

The issue involved in local symbols is modularity. Another aspect of 
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modularity has to do with relocatable code. The assembler takes care 
of assigning specific memory locations to the instructions appearing in 
a source file; the programmer refers to any locations that need to be 
addressed by using symbolic names. The assembler assigns values to 
these names (see Figure 3.3) and assembles the proper values into the 
instructions using them. This all depends upon assembling the entire 
program at once. 

If the programmer wishes to combine separate programs or to break 
up a program into logically independent pieces, then the assembler can 
no longer assign memory locations or assemble actual values for re¬ 
ferences to symbols in one piece by instructions in another. In this case 
the assembler produces relocatable code, and the task of assembling 
actual values for instructions in one piece that refer to another is left 
to the relocating loader (also called a linkage editor). This program 
takes the object files output by the assembler and assigns actual 
memory locations to them (i.e., relocates them). It is the job of the 
programmer to declare which symbols in any given source file are to 
be referred to from other source files and which symbols referred to in 
the given source file are expected to be supplied from other source 
files. Symbols to be referred to from other source files are called 
globals or entries', symbols to be supplied from other source files are 
called externals. Thus, it is the programmer’s job to declare globals or 
entries and externals. 

In Chapter III we talked about how to implement statements of the 
form 


IF (so and so) THEN (one thing) ELSE (the other) 

by means of tests and branches. (See Figure 3.2.) Statements of this 
form are usually available in higher level languages like PASCAL or 
C, but they are seldom found in assembly languages. 

The remaining two items in our list are the most important: macros 
and conditional assembly. To understand them it will help to look at 
the assembler in a new way. Think of the assembler as a machine to 
which the source file is being fed one character at a time. This 
succession of characters is called the assembler’s input stream. Macros 
and conditional assembly are ways to alter the assembler’s input 
stream. 

A conditional assembly statement takes the form 
IF (condition) THEN text 
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If the condition is true, then the characters of text become the next 
piece of the input stream; otherwise, the stream continues with the 
next statement after the conditional assembly statement. Variations 
like 


IF (condition) THEN text 1 ELSE text 2 
are handled similarly. 

A macro works by text replacement. When a particular sequence of 
characters appears in the source file, a preordained substitute string is 
fed into the input stream. This can be repeated to any depth, that is, if 
the substitute string contains macros, then their substitute strings are 
used. The preordained substitute strings are specified in macro 
definitions. Here is an example. 

Notice in Figure 6.13 that the sequence of instructions 

LD Rl, LINE; LDB RL0,CHAR; CALL ADLINE 

appears twice: at ECES and at ECC. Suppose that at the beginning 
of Figure 6.13 or at the start of Figure 6.12 or even in Figure 6.11 we 
had placed the definition 

PUTLINE = “LDR1,LINE; LDB RL0,CHAR; CALL ADLINE” 

With this macro definition we could now write PUTLINE in each of 
the two places where the sequence of three instructions had previously 
appeared. The source file would then be shorter and easier to read. 
The actual instructions generated would not change, since, whenever 
PUTLINE was encountered, the original three instructions would be 
fed into the input stream. 

Now look again at Figure 6.13. At ECCR there appears the 
sequence 


LD Rl ,LINE; LDB RL0,#TRM; CALL ADLINE 

which is identical to the previous sequence except for the appear¬ 
ance of CHAR in the original and #TRM in this one. Now suppose 
that our definition read 

PUTLINEx = ”LDR1,LINE; LDB RL0,x; CALL ADLINE” 
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With this definition we could write 


PUTLINE CHAR 


for the original two occurrences and 

PUTLINE #TRM 

for the most recent one. In this case x is called a parameter of the 
macro PUTLINE. 

Finally, here is an example combining conditional assembly and 
macros 


SUM x,y = IF X is a register THEN 
“ADDx,y” 

ELSE 

“PUSH@SR,R0 
LD R0,x; ADD R0,y; LD x,R0 
POP R0,@SR” 


So SUM R0,R1 generates ADD R0,R1; but if TEMP is a memory 
location, then SUM TEMP,R1 generates 


PUSH @SR,R0 

LD R0,TEMP; ADD R0,R1; LD TEMP,R0 
POP R0,@SR 


This last example shows just the tip of the iceberg. The combination 
of a macro capability with conditional assembly allows the 
programmer to transform the original assembly language into a 
powerful tool geared to the specific application at hand. 

The syntax presented here for conditional assembly and for macro 
definition is not that of any specific assembler, and there is no 
uniformity or standardization in this area. You will have to learn the 
syntax appropriate to your particular system. 

In Chapter I we said that the subroutine is the programmer’s single 
most important tool. Macros, especially with conditional assembly, 
are number two. 
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Debugging Tools 


The earliest debugging tools, used in batch processing environments, 
were the dump and the trace\ they are still used today. The dump, in 
its crudest form, is a hexadecimal listing of the contents of all memory 
locations having any relation to the program being executed. The trace 
is a mechanism whereby the executing program is modified (or exe¬ 
cuted interpretively by a simulation program) so that selected 
information is printed at chosen points in the program execution. For 
example, the contents of certain memory locations might be printed 
after each execution of the body of a loop, or the name (or hexa¬ 
decimal address) of selected subroutines could be printed each time 
they are called. 

When interactive programming environments developed, interactive 
debuggers became possible. The first widely used one was ODT for 
the PDP-8. ODT stands for Octal Debugging Tape: octal, because the 
12-bit addresses and word contents of the PDP-8 were always regarded 
as four octal digits rather than as three hexadecimal digits; tape, be¬ 
cause this program was supplied on a paper tape, to be loaded using 
the paper tape reader of the console teletype. The main features of an 
interactive debugger are: 

• Examination and modification of selected memory locations 

• Breakpoints. 

The first of these represents the evolution of the dump; the second 
represents the evolution of the trace. Here is an example of how you 
might use an interactive debugger with a Z8000 program. 

Suppose that you are checking out the routine SAY of Figure 8.10. 
You wish to know that it sets up the table properly for the call to 
TYIO. Let us assume that we have our debugger loaded into memory 
at address 2000, the program of Figure 8.12 at address 1000 and the 
routines of Figure 8.10 so loaded that the CALL TYIO instruction of 
SAY is at address E16. You begin by starting at address 2000. The 
debugger prompts you for a command and you instruct it to place a 
breakpoint at E16, that is, you wish execution of the program to 
proceed right up to the call to TYIO. Then you want to examine the 
table that SAY has set up on the stack. 

After noting your request for a breakpoint, the debugger prompts 
you for another command, and you tell it to begin execution of the 
program at address 1000. Almost immediately you will be notified that 
you have reached a breakpoint at E16. You examine R1 to find out 
where in memory the TYIO table is stored; then you examine the 
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memory locations starting at that address to see whether they are as 
you hoped. If so, you may direct the debugger to place another break¬ 
point somewhere further along in the process and to continue 
executing at the point where it had placed the original breakpoint 
(i.e., E16). If not, you may wish to place a breakpoint somewhere 
earlier in the process and tell the debugger to restart at 1000. 

We have not discussed how the debugger implements breakpoints. 
One obvious way would be to dedicate one of the 256 SC entries to this 
function. Then the debugger, just before it transferred control to the 
program being tested, could replace the contents of the specified break¬ 
point location(s) with the appropriate SC instruction. This requires 
that instruction memory can be written into and that the program’s 
instruction memory is in the debugger’s data memory. The easiest way 
to assure the latter is to avoid separate data and instruction address 
spaces. 

The interactive debugger is useful in cases where the flow of control 
in the situation under test is well defined and where the action of the 
debugger does not change the behavior of the CPU or program in any 
way that affects the outcome of the test. When interrupts or 
timesharing are affecting the situation being tested, or when 
symptoms such as unexplained changes to memory locations are 
occurring, then another kind of tool is useful. This is called an in-cir- 
cuit emulator (ICE), which evolved from the “trap box” of the mini¬ 
computer environment. 

The basic idea of the in-circuit emulator is that it plugs directly into 
the CPU chip socket (in place of the CPU) and sends signals back to a 
recording and monitoring system that “triggers” on certain combina¬ 
tions of signals on the CPU chip lines and on other selected signal 
lines. The states of these signals at each clock cycle in a specified “win¬ 
dow” around the triggering event are saved for later examination. 

Originally, in-circuit emulators, like their trap box predecessors, 
were designed around specific microprocessors. But most modern 
emulators use general triggering and recording logic with specific 
“personality boards” that determine which microprocessor is being 
emulated. Thus, the programmer’s interaction with the emulator will 
be specific to the emulation system, not to the microprocessor being 
emulated. 

Development Hardware 

There are two kinds of hardware used for microprocessor program 
development: development systems and “single-board computers.” A 
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development system is a full-scale configuration with secondary 
storage units (e.g., floppy disks) and plenty of RAM for running edits 
and assemblies. A single-board computer has a CPU, some I/O cir¬ 
cuits, a small amount of RAM, a ROM containing a hex debugger and 
loader and a wirewrap area for prototype hardware development. 

Programs to be run on the single-board computer must either be 
entered from a terminal using the hex debugger or be loaded from the 
terminal’s paper tape or cassette unit in machine code format after 
having been assembled somewhere else. A variation on this last 
alternative is a “down-line load,” in which an attached development 
system simulates the paper tape or cassette. If only very small 
programs are to be run on the single-board computer, they can be 
assembled by hand using the method illustrated in Chapter IV; in that 
case the development system can be dispensed with. But this only 
makes sense if the Z8000 programs involved are very small and infre¬ 
quently changed. 

On the other hand, the user of a ZSOOO development system cannot 
dispense with the single-board computer and run programs on the 
development system’s ZSOOO for one very simple reason: the develop¬ 
ment system may not have a ZSOOO in it. For example, the first com¬ 
mercially available ZSOOO development system is ZSO-based. This is 
not an unusual situation; it is true of development systems for other 
microprocessors as well. After all, it makes very little difference what 
CPU the editor or the ZSOOO assembler runs on. As with in-circuit 
emulators, it is much easier to graft a new CPU onto an established 
system than to built a new system for it. 

Figure 10.1 shows a possible development configuration. Each 
single-board computer has its own terminal, and one of them at a time 
can be connected to the development system for editing, assembling 
and down-line loading. There are single-board ZSOOO computers 
available that allow their attached terminals to talk directly to the 
development system if the programmer wishes to do so. 

Incidentally, one last point to note about the first commercially 
available single-board computers is that they use the ZSO-family SIO, 
PIO and CTC circuits. Later versions of these single-board computers 
can be expected to use ZSOOO family circuits. 
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Development 

System 



Several single-board computers attached one at a time to one development 
system. The SBC's terminal becomes the development system's terminal when 
the SBC is attached. 

10.1: A Possible Development Configuration 
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APPENDIX A 

Answers to Selected Exercises 


Chapter I 

I. Step 3 is performed four times. Steps I, 2 and 7 are performed 
once each. Step 3 would be performed six times if 112 were on top and 
12573 were below. 

3. 7 = llh. 196,0 = IIOOOIOO 2 . 

4. 196,0 = IIOOOIOO 2 = 11002 x 2 “ + 0100 = CX16+4 = C4,o. 

5. Three bits distinguish eight items (8 = 2’). For twelve states, 
four bits are needed (2“ = 16 >12, 2’ = 8 < 12). Four hex digits can 
represent 16“ = 65,536 different numbers. Eight hex digits can represent 
16* = 4,294,967,296 different numbers. 

6. 196 ^ 16 = 12 with remainder 4. Final digit is 4. 12 -r- 16 = 0 
with remainder 12. First digit is C ( = 12). Therefore, 196, 0 = C4,6. 

7. B + B = 16. lA + B1 = CB. = 64. 1B93F - 2B5 = A3. 

8. -5 is represented by FFFB. -7FFF = 8001. -lAl = FE5F. 
Thus, FF7 - lAl = FF7 + FE5F = E56. (-1) + (-5) = -6. 
(-7FFE) + (-6) = +7FFC. 

9 . 6 - 4 = 2; C = 0. BB - BC = - 1; C = 1. FFFF + 3 = 2; 
C = 1. FFFF + FFFF = FFFE; C = 1. 

10. V = 0 for 6 - 4, BB - BC, FFFF + FFFF. (- 17) + (-7FF1) 
= +7FF8;C = 1;V = 1. 

II. (a) Initialize N to zero. 

(b) Receive next digit. If “x”, then done. 

(c) Multiply N by A (= 10) and add the value of the digit. Re¬ 
place N by the result of this computation. 

(d) Go back to step (b). 

12. 16 bits can represent 4 BCD digits. Thus, 16 bits can represent 
10,000 BCD numbers (10,000 = 10“). 16 bits can represent 65,536 
hex numbers (65,536 = 16“). The rule is: 4n bits can represent 10" 
BCD numbers or 16" hex numbers. The ratio is (10/16)". 

15. “Hi! I’m a Z8000.’’ can be represented in ASCII by: 48,69,21,20, 
49,27,6D,20,61,20,5A,38,30,30,30,2E. (See Figure 1.15.) 
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Chapter III 


1. 48^0 = 48. 48^48 = 0. FOA^OF = FF. 

2. 4 mod 3 = 1. 

3. The encrypted version of “Hi! Fm a 28000.” is: 29,OB,53,41,2A, 
46,09,41,03,52,3B,59,52,42,51,4D,0. Three of these characters are 
non-printing: OB (VT), 09 (HT) and 03 (ETX). Replacing each of these 
by “. ” gives the following text: 

).SA*F.A.R;YRBQM 

4. -X- 1 = -(x -h 1). 

Chapter VI 

1. (a) ADDL RR0,#1 requires 14 cycles. 

JR NZ,x requires 6 cycles. 

Thus, each iteration of the loop uses 20 cycles, i.e., 5 /i s at 4 
MHz. 

(2.4xl0«) X (5xl0~^) = 1.2xl0^sec = 

1200 sec = 20 minutes. 

(b) 10 cycles at 4 MHz = 2.5 ^s. 

3. (a) 100 ms/second (11 bits/character x 10 characters/second) 

= 1000/110 ms/bit = 9.091 ms/bit. 


Chapter VII 

2. Subtracting 400 corresponds to updating the clock by 10 ms. The 
amount remaining after the subtraction is a legitimate part of the next 
10 ms. Resetting to zero instead of subtracting 400 would cause the 
clock to lose time. All time between the moment at which the counter 
reached 400 and the moment at which it was reset to zero would be lost. 

Chapter VIII 

1. If TYENT is in its loop at TYWSM, then TYWAIT will not ever 
finish its test, since the execution of TYWAIT is suspended, pending 
completion of the interrupt processing. 
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5. SUFTAB: 


1, “St” 

2, “nd” 

3, “rd” 

21, “st” 

22, “nd” 

23, “rd” 

31, “st” 

0, “th” ! Default = ‘ 


‘th”, e.g., 4th, 5th, etc. ! 
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APPENDIX B 

ASCII Character Set 


CODE CHAR 

CODE CHAR 

CODE CHAR 

CODE CHAR 

00 

NUL 

20' 


40 

@ 

60’ 

V 

01 

SOH 

21 

! 

41 

A 

61 

a 

02 

STX 

22 


42 

B 

62 

b 

03 

ETX 

23 

n 

43 

C 

63 

c 

04 

EOT 

24 

$ 

44 

D 

64 

d 

05 

ENQ 

25 

% 

45 

E 

65 

e 

06 

ACK 

26 

& 

46 

F 

66 

f 

07 

BEL 

27^ 


47 

G 

67 

g 

08 

BS 

28 

( 

48 

H 

68 

h 

09 

TAB 

29 

) 

49 

1 

69 

i 

OA 

LF 

2A 

* 

4A 

J 

6A 

i 

OB 

VT 

2B 

+ 

4B 

K 

6B 

k 

OC 

FF 

2C3 

/ 

4C 

L 

6C 

1 

OD 

CR 

2D 

- 

4D 

M 

6D 

m 

OE 

SO 

2E 


4E 

N 

6E 

n 

OF 

SI 

2F 

/ 

4F 

O 

6F 

a 

10 

DLE 

30 

0 

50 

P 

70 

P 

11 

DCl 

31 

1 

51 

Q 

71 

q 

12 

DC2 

32 

2 

52 

R 

72 

r 

13 

DCS 

33 

3 

53 

S 

73 

s 

14 

DC4 

34 

4 

54 

T 

74 

t 

15 

NAK 

35 

5 

55 

U 

75 

u 

16 

SYN 

36 

6 

56 

V 

76 

V 

17 

ETB 

37 

7 

57 

W 

77 

w 

18 

CAN 

38 

8 

58 

X 

78 

X 

19 

EM 

39 

9 

59 

Y 

79 

y 

lA 

SUB 

3A 


5A 

Z 

7A 

z 

IB 

ESC 

3B 

; 

5B 

[ 

7B 

{ 

1C 

FS 

3C 

< 

5C 

\ 

7C 

1 

ID 

GS 

3D 


5D 

] 

7D’ 

} 

IE 

RS 

3E 

> 

5E 


7E 


IF 

US 

3F 

? 

5F’ 

<r 

7F^ 

RUBOUT 


'space ^comma ’accent mark ^or DEL 

^single quate ^ar underline ’or ALT MODE 


) 











APPENDIX C 

Encodings for Instruction Fields 


Mode 

Field 

Src 

Register 

Address Mode 

Dst 

Register 

Address Mode 

0 

1-15 

Indirect Register (@) 

0-15* 

Indirect Register (@) 

0 

0 

Immediate (^) 



4 

1-15 

Indexed(X) 

1-15 

Indexed(X) 

4 

0 

Direct Address (DA) 

0 

Direct Address (DA) 

8 

0-15 

Register (R) 

0-15 

Register (R) 


*See CAUTION note on page 99. 

Encoding of Address Mode Using Mode and Register 


CONDITION 
CODE (Hex) 

MEANING 

MNEMONICS 

CONDITION 

CODE (Hex) MEANING MNEMONICS 

0 

False 

none 

8 

True 

blank* 

1 

SXORV = 1 

LT 

9 

SXORV = 

0 GE 

2 

LTORZ = 1 

LE 

A 

LTORZ = 

0 GT 

3 

CORZ = 1 

ULE 

B 

CORZ = 

0 UGT 

4 

V/P = 1 

OV,PE 

c 

V/P = 0 

NOV,PO 

5 

S = 1 

Ml 

D 

0^ 

II 

o 

PL 

6 

Z = 1 

Z,EQ 

E 

Z = 0 

NZ,NE 

7 

C = 1 

QUIT 

F 

C = 0 

NC,UGE 


default case (e.g., JR X gets 8 in cc field) 

Condition Codes 
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HEX 

MEANINGS 

HEX 

MEANINGS 

0 

R0,RH0,RR0,RQ0 

8 

R8,RL0,RR8,RQ8 

1 

R1,RH1 

9 

R9,RL1 

2 

R2,RH2,RR2 

A 

R10,RL2,RR10 

3 

R3,RH3 

B 

R11,RL3 

4 

R4,RH4,RR4,RQ4 

C 

R12,RL4,RR12,RQ12 

5 

R5,RH5 

D 

R13,RL5 

6 

R6,RH6,RR6 

E 

R14,RL6,RR14 

7 

R7,RH7 

F 

R15,RL7 


Interpretation of Register Fields in Instructions 


T—I —I— I — T — I — I — I —r—I—r—I—I—I—r 

Address 

1 1 ************ * 

NON-SEGMENTED ADDRESS 
16 bits address 65,536 bytes 


0 

. I 1 - 1 - 1 - 1 - 1 - 

Segment number 

—r .1. r-T" . 1—1 1 

RESERVED 


1 • • 1 f f 

Address within S 

Lilli_1 1 J 

legment (offset) 


LONG SEGMENTED ADDRESS 
23 bits address 8,388,608 bytes 
7-bit segment number addresses 128 segments 
16-bit offset addresses 65,536 bytes 



-1-1-1-1- 

Segment Number 

-1 1 1 1 ? 1 1- 

Offset 

1_ 

-L—1-1-1_1_l_ 

-^ ^ ^ ^ « 


SHORT SEGMENTED ADDRESS 
15 bits address 32,768 bytes 
7-bit segment number addresses 128 segments 
8-bit offset addresses 256 bytes 

Address Formats Used in Instructions 
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APPENDIX D 

Control Register Formats 


|Zg 

S/N 

D 

VIE 

NVIE 

- 1 - 1 - 

1 1 

B 

0 

0 

P/V 

0 

0 

1 

15 

14 

13 

12 

11 

10 9 8 

7 

6 

5 

4 

3 

2 

1 0 


Bit Assignments in Fiag Controi Word(FCW) 


RE 


RATE 


ROW 


15 14 13 12 11 10 9 8 7 6 5 4 3 2 10 

Fieid Locations in REFRESH Register 


0 

—1-1-1-1-1-1- 

Segment Number 

A A A A A A 

-1-1- 

0 

— 1- 

-1-1- 

0 


Off 

L 1 1 i 1 J_1-1 

set 

\ i JL J 

t f 

L.A_ 

1 i 1._ 


Low order 8 bits of PSAP offset ore always zero 


Format for PSAP and NSP 



APPENDIX E 

Layout of Program Status Area 

Address (hex) 


(Unused) 


PSAP Control Register 


Program Status for 
Unimplemented Instruction 
Trap 


Program Status for 
Privileged Instruction 
Trap 


Program Status for 
System Call Trap 


Program Status for 
Segmentation Trap 


Program Status for 
Non-Maskable Interrupt 
(NMI) 


Program Status for 
Non-Vectored Interrupt 
(NVI) 


FCW for Vectored Interrupt 


PC for lnt#0 


PC for Int #s 


PC for Int #2s 


The address x of the final vec¬ 
tored interrupt PC is ICs H- 200. That 
is, the PC table is 512 bytes long, 
regardless of the value of s. Note 
that when s = 2, the vectored in¬ 
terrupts numbered 1,3,5,... don't 
exist. They must not be used. 



Program Status for 
Typical Vectored Interrupt 
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APPENDIX F 

Extended Processing Architecture 

The ZSOOO instruction set is “extensible.” When bit 13 of the FCW 
is set, the “unimplemented instruction” trap is disabled. The CPU 
can then execute the instructions (with “unimplemented” opcodes OE 
and OF) designed to allow communication with, and control of, “slave” 
processor chips called Extended Processing Units (EPU’s). 

There are three types of instruction for use with the EPA. The first 
type of instruction is like an LDM for the EPU. The EPU is either the 
source or the destination, and a block of 1 to 16 CPU registers or 
memory locations is the other argument. This type of instruction uses 
opcode OF, otherwise, the format and timings are the same as for the 
LDM instruction. The second type of instruction allows a transfer 
between the CPU FLAGS register and the EPU. Either the EPU or the 
FLAGS register can be the source or the destination. Instructions of 
this type use opcode 8E. The final type of instruction, also using op¬ 
code 8E, commands internal EPU operations. Unused fields in the 
two-word instruction encode the operation to be performed. 

The status lines ST 3 -ST 0 are used to indicate transfers between the 
EPU and memory (hex value A denotes data memory, B denotes stack 
memory) or between EPU and CPU (hex E). 

The CPU STOP line is used by the EPU to force the CPU to pause 
if the CPU fetches an EPU instruction while the EPU is still executing 
a prior instruction. This is the only “handshaking” necessary to syn¬ 
chronize the CPU and EPU. 

The Extended Processing Architecture allows software to be used to 
simulate the action of an EPU if the actual hardware is not in place. 
This is accomplished through use of the “unimplemented instruction” 
trap. If the EPA bit (bit 13) of the FCW is clear, then the “unimple¬ 
mented instruction” trap occurs whenever the CPU encounters the 
opcode OE or the opcode OF. 
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INDEX 


Address/data bus, 37,48,185-86,211-12 
Addressing mode, 177-84 
autoincrement/autodecrement, 67,90 
based, 31, 83,178-79, 222,251 
base indexed, 31,74, 83 
immediate, 60,181-82 
indexed, 31,62,178-79 
indirect register, 31,61 
instruction formats for, 35, 97,98-99 
relative, 95-96 

Address space, 38,49-50, 83, 86,183, 

196,208, 283 
Algorithm, 5, 8, 9, 199 
for decimal-to-hex conversion, 14-16 
for encrypting text, 53-55 
for multiplication, 6,9 
ASCII, 25-26, 53,188-89, 223 
Assembler, 57-59,97,108-10,111-13, 
275-76, 277-81 

Associative search, 205,227-29 
Bit, 8,13 

Bit pattern, 99. See also Bit; Byte; Digit; 

Long-word; Word 
Bit table, 243-45 
Byte, 8, 30 

Component family, 214,284 
Conditional assembly, 279-81 
Condition code, 78-80,92, 94, 96 
instruction formats for, 130-31,145, 
166,172 

Context switching, 83, 202-5, 223,229-31, 
245, 256-58 

Control register, 45-46, 88,150-51. See 
also FLAGS 
FCW, 39-40,45 

NSP (NSPSEG, NSPOFF), 38,45 
PSAP (PSAPSEG, PSAPOFF), 43, 45, 
150-51,267 

REFRESH, 45-46, 140, 161, 215-16, 270 
CPU status, 30,43-44, 267. See also In¬ 
struction, CPU control, LDPS; Pro¬ 
gram status area 
Cursor control, 241-42 
Data transmission. See also Terminal 
interaction 
bandwidth, 193-94 
control character, 25 


data bus format (byte/word) for, 211-12 

echoing, 189,199 

half and full duplex, 189 

serial, 188-90,214 

parallel, 190-93,215 

parity, 25 

priming output interrupt for, 192,271 
Deadly embrace, 221 -22 
Debugging facility, 276,282-83 
Development system, 284-85 
Digit (hex), 8 

Distributed processing, 46-48, 50. See also 
Semaphore; Instruction, multi-micro 
sync 

Dynamic memory, 46 
Editor, 275, 111 
Encryption, 51-55 
Entries (to program), 279 
Exclusive OR, 54. See also Instruction, 
data operation and testing, logical 
Exponent (in floating point representa¬ 
tion), 23 
Externals, 279 

FLAGS, 39-40, 45, 92, 94,100,106-7,128 
effect of instructions on, 62,76,82,86, 
87, 88,90,92 
Cbit of, 205-6,268 
Flowchart. See Algorithm 
Global and local symbols, 67,278,279 
In-circuit emulator (ICE), 283 
Initialization, 266-73 
Input decoding, 233-38 
Input/output scheduling, 197-99 
Input stream, 279-80 
Instruction description, 99-113 
Instruction format, 94-99,108-10,111-13, 
179-81,181-82,183 
Instruction, block, 68-69, 88, 90-92 
Instruction, CPU control, 40,46, 88 
Instruction, data operation and testing: 
arithmetic, 20,22, 71, 76 
counter/pointer varying, 63,78 
logical, 54, 76-77, 78 
shift/rotate, 72, 77-78, 79 
testing, 62,78-80. See also Instruction, 
block 
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Instruction, data transfer, 81-85 
constant transfer, 60,67 
stack transfer, 32 

variable transfer, 60,63,95-96. See also 
Instruction, block 

Instruction, input/output, 87-88,186, 
211-12. See also Instruction, block 
Instruction, multi-micro sync, 92 
Instruction, pointer setting, 35, 59,86 
Instruction, transfer of control, 86-87 
interrupt/trap, 43,264-66,283 
jump, 62,64-65, 95-96 
subroutine, 60,65-67,95-96 
Interrupts and traps, 40-45,197-99, 
199-209, 267, 271 

interference with non-interrupt opera¬ 
tion by, 45,90,150-51,218, 220 
NMI, NVI, VI, 40,45,50 
traps, 43, 87,270 

An Introduction to the Z8010 MMU 
(Stevenson), 212 
Langer, R.S., 228 
Loader, 276, 279 

Local symbol. See Global and local 
symbols 

Location counter, 57-59,183. See also 
Addressing mode, relative 
Long-word, 8 
Macro, 280-81 
Mantissa, 23 

Memory mapping, 35-38, 212-13, 267. See 
also Memory segmentation 
Memory segmentation, 34-35, 50,101-2, 
179-81, 222, 251. See also Memory 
mapping 

Mode field, 96, 97 
Mod function, 54-55, 71-72 
Normalization (of floating point 
numbers), 24 
Notational convention: 

B and L endings, 61 

cc, 96 

colon(:), 61 

dollar sign ($), 183 

dst and src, 97 

hex (for field values), 98 

number base as subscript, 12 

op, 100 

parentheses, 75 
percent sign (<^7o), 60 
W, 96 
#,60 
V;54 

Number representation, 9,10,11,12, 
16-20, 21-22, 23-25 


Object file, 276 
Opcode field, 96 
Output formatting, 238-40 
PDP-11 (Digital Equipment Corporation), 
29,62,63,267 
Polling, 197-99 

Position-independent code, 110 
Privileged instruction, 38, 88,92,93,267 
Program counter, 39,87,95-96. See also 
CPU status; Instruction, transfer of 
control 

Program status area, 43-44,267,268-69. 

See also Control register, PSAP 
Program structure and style, 55,62,64, 

86, 229, 235 
comments, 55,194 
IF-THEN-ELSE form, 61, 279 
loop, 7, 59 
semicolon, 190 
RAM, 248 
Recognizer, 235 

Refresh cycle. See Control register, 
REFRESH 

Register, 30, 32, 34, 59, 98-99,183, 222. 

See also Stacks; Control register 
Relocatable code, 278-79 
RESET, 50,267 
Ring buffer, 223-26 
ROM, 247-48 

Round robin, 197-98, 256-58 
Saving and restoring register values, 45, 
70, 83. See also Context switching 
Semaphore, 176, 221-22. See also Instruc¬ 
tion, data operation and testing, 
testing 

Semicolon. See Program structure and 
style 

Seven-segment code, 194-97 
Shareable program, 248 
Side effect, 70 

Single-board computer (SBC), 284-85 
Software Tools (Kernighan and Plauger), 
51 

Special note, 126, 132,136,137,161, 270 
Stacks, 32-34,42, 65-67, 83,183 
implied register for, 34, 35, 38, 267-68 
management of, 258-64 
Status outputs, 38, 49-50, 141, 183, 211-12 
Subroutine, 60, 64, 65-67, 205-6, 260-64 
Symbolic names, 57, 59,61, 203,222, 278 
System and normal modes, 38,40,49. See 
also Privileged instruction; Control 
register, NSP 

System entry routine, 260-64 
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Terminal interaction, 189, 218-19, 254 
priming output interrupt for, 192, 271 
programs for, 199-209, 229-33 
“reason”, used for, 253, 266 
Text editor. See Editor 
Text representation, 25-28, 53, 208, 275, 
277, 278. See also ASCII; Data trans¬ 
mission 

Timesharing, 248-58 

Timing (instruction), 68-69,101-2,105-6, 
186-87, 215-16 

Traps. See Interrupts and traps 
Underflow (in floating point representa¬ 
tion), 24 
User, 249, 254 
Word, 8, 29 

Z80A components, 214, 215, 284 
Z8001 and Z8002, 29, 39,40,45,49,144 
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